Re: [reSIProcate] rendIt on osx
On 03/09/13 23:10, Jason Fischl wrote:
> I just moved over to Linux (debian) to avoid the osx issues. I am
> still having lots of trouble.
> I'm having problems getting tfm built at the moment. When I try to run
> dumTests, here's what I see.
>
> jfischl@jason001:~/resiprocate/tfm/tfdum$ ./dumTests
> /home/jfischl/resiprocate/tfm/tfdum/.libs/lt-dumTests: error while
> loading shared libraries: libNetxx.so.1: cannot open shared object
> file: No such file or directory
Netxx and all the contrib stuff is no longer distributed in the usual
source tarball because we aim to have all that packaged on Linux
distributions. You can either get it from the contrib tarball, or more
likely, you can grab the package from unstable, it just went into Debian
last week:
http://packages.qa.debian.org/n/netxx.html
You need the libnetxx-dev package as well as the shared library package
main also uses cajun, that has just been packaged too but I haven't
removed it from the repository yet, it will move to contrib in the
coming days.
> jfischl@jason001:~/resiprocate/tfm/tfdum$ ldd ./.libs/dumTests
> linux-vdso.so.1 => (0x00007ffff1d6f000)
> libtfmrepro.so.0 => not found
> libtfm-1.9.so => not found
> libdum-1.9.so => not found
> libresip-1.9.so => not found
> librutil-1.9.so => not found
That is normal
When you run binaries from the source tree, libtool provides convenient
wrapper scripts to build LD_LIBRARY_PATH so you'll get the corresponding
libs from the same source tree and not accidentally end up linking
against any libs you already installed to /usr/lib
If you look at tfm/tfdum/dumTests you should find it is a script to run
.libs/dumTests with the correct LD_LIBRARY_PATH
> libcppunit-1.12.so.1 => /usr/lib/libcppunit-1.12.so.1 (0x00007f7ba7774000)
> libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007f7ba7567000)
> libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> (0x00007f7ba7308000)
> libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> (0x00007f7ba6f23000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7ba6d07000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7ba6aff000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x00007f7ba67f7000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7ba6575000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7ba635f000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ba5fd4000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7ba5dd0000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7ba5bb9000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7ba79c0000)
>
>
> On Tue, Sep 3, 2013 at 2:05 PM, Daniel Pocock <daniel@xxxxxxxxxxxxx> wrote:
>>
>>
>> On 03/09/13 22:58, Jason Fischl wrote:
>>> Hey Daniel. I'm having trouble getting lots of things working under
>>> the new build system. What do I need to do to revert back to the old
>>> build system?
>>
>> I did do some tests on OS X, I put some comments here (look about half
>> way down):
>>
>> http://www.resiprocate.org/Configuration_Options
>>
>> If you are still stuck, please let me know more about the problems you
>> encounter, you can also query things on the autotools lists, they
>> usually respond very quickly
>>
>> It is very awkward to support multiple build systems and so the old
>> system isn't really supported from v1.8 and beyond. This has allowed us
>> to push into the world of packaged software very effectively but I don't
>> want to leave behind other platforms.