Hi Matthias, > libbar.so needs to be linked with libm.
I disagree. libbar,so should have been linked with -lm to circumvent the problem, but it happens not to be like this. I looked around in the internet, but found nowhere written that a valid shared object *must* have all dependencies resolved when it is created. Rather, there are good reasons to leave this open: - use of standardized interfaces, that may be provided by a variety of libraries (e.g. MPI, BLAS) - linkage to an optimized library for single-threaded/multi-threaded programs (e.g. mkl) According to my understanding, a bug-free linker must be able to deal with the situation that some symbols in the shared object will only be resolved with additional libraries that the shared object does not know about. The current linker does this correctly if this particular library is not indirectly used by a second (libfoo) library *offered* to the linker. If the linker figures out that libfoo is not needed, it MUST not conclude that the explicit -lm appearing later on is not needed. In summary: - libfoo.so and libbar.so are valid shared objects - the dependency of libbar on libm is resolved in the linker command line => the linker MUST be able to link everything together Please accept that the current behavior of ld is a misbehavior. I am saying this not to annoy you, but because the current setup causes us severe headache to build up a versatile set of libraries for high- performance computing that ultimately rely on highly specialized low- level numerical libraries with standardized interfaces. Many thanks, Christoph -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/945927 Title: ld incorrectly gives 'undefined reference' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/945927/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
