Bugzilla – Bug 346
ns-3 fails to build if librt is not found
Last modified: 2009-01-26 19:35:16 UTC
librt is not marked as mandatory in the ns-3 build, but if it doesn't exist, ns-3 programs will not link. Problem one is that they still require clock_getres, which is in librt. Problem two is that they still require pthread functions. If ns-3 programs are not linked with librt, nothing pulls in pthread. On my system I can compile with -pthread, but I do not have librt installed. Nor is it easy to install, because I am building ns-3 with a 32-bit cross-compiler. The actual errors are just undefined dependency errors: $ ./waf Entering directory `/usr/local/home/nsc/ns-3-dev/build' [469/507] cxx_link: build/debug/samples/main-callback_2.o -> build/debug/samples/main-callback i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_join' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_create' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_mutexattr_init' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_mutexattr_settype' i686-unknown-linux-gnu/bin/ld: debug/libns3.so: undefined reference to 'pthread_condattr_setpshared' collect2: ld returned 1 exit status It only got this far after I fixed the dependency on clock_getres by patching src/simulator/wall-clock-simulator to only call this function if HAVE_RT is defined. This makes it rather hard for me to do 32-bit versus 64-bit testing of NSC which is required for the regression testing of the NSC component of ns-3. I pulled ns-3 from mercurial this morning (9am PDT, September 13 2008). The gcc version is 4.2.2.
A little bit of extra information: I do actually have librt installed, it's just in a non-standard place (/lib32 for 32-bit compat libs). Perhaps the resolution to this bug is that librt should be mandatory? I'm not sure. My next problem is that I don't know how to make waf add /lib32 to the search path from the command line. The documentation, of course, isn't helping.
If /lib32 was important it would be already found by the tools, no need to set it. To compile with non-standard link path, use the environment variable LINKFLAGS. Example: LINKFLAGS="-L/tmp" ./waf configure
Please don't mark a bug as resolved if you are unable to test it yourself, which I assume you haven't done here. Because this doesn't quite work as advertised. Also, what you suggest doesn't actually solve the problem reported: ns-3 should either build on a machine without librt (it doesn't); or configure should tell the user they need librt installed to build ns-3 (it doesn't). Back to my particular issue: I did actually try LINKFLAGS in my earlier tests and assumed it did nothing, but I see now it does pass in the LINKFLAGS, but there is another problem underlying this. What happens is this (from build/config.log): ...etc...-g++ debug/test_11.o -o debug/testprog -L/lib32 -L/usr/lib/ -Wl,-Bdynamic -lrt collect2: ld terminated with signal 11 [Segmentation fault] ...etc.../i686-unknown-linux-gnu/bin/ld: /usr/lib//librt.so: not configured to support 64-bit little-endian object The problem here is that something in the build is adding -L/usr/lib into the link line; which doesn't work if you're using a cross compiler.
So basically the real issue is "ns-3 cross-compiling is not working" (and please retitle the bug if you agree with me). That does not surprise me: no one ever claimed ns-3 could be cross-compiled or that it was supported. Personally I think it would be nice to support cross-compilation. However, making it work is not trivial as you are finding out, and I am not willing to devote much of my time to getting it to work. But if anyone wants to devote some time to it and come up with a patch, I'll be happy to review it.
Well, I understand if ns-3 people don't want to spend too much time on supporting cross-compiling -- it's not something I've done a lot myself in the past. But the bug I'm reporting is just a missing library causing configure / the build to not work in a rational way. If a user had an installation where librt could not be found or did not exist, they would get the same error, irrespective of whether a cross compiler is being used. I think its reasonable to fix that (and I completely understand if the fix is to make librt a required component).
I think/hope this is fixed in trunk. Can you check?
Great! I just built a 32-bit binary on my 64-bit machine using a cross compiler. The build works perfectly. Thanks a lot.