Domenico Andreoli <cavok@filibusta.crema.unimi.it> writes: > what i don't understand follows: > "*** Warning: inter-library dependencies are not known to be supported. > *** All declared inter-library dependencies are being dropped. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it." > > i suppose the command following this statement fails because of the > problem claimed by it, but i still don't figure out what does it means. Normally, when you "link in" a shared library into a program, the program will not contain code from that library, just stubs that are resolved at runtime *and* will depend on it. This dependencies are what shows up on "ldd BINARY". If you link a shared library with a shared library, the same should happen, but some library formats do not support this feature. The message means that libtool suspects this system to be one of these. (see also "(libtool)Inter-library Dependencies" in the info pages). libtool is actually wrong, because all common Linux ports use ELF, which supports inter-library dependencies (accordingly, you can see those with "ldd LIBRARY"). I don't think that the following error (libtool issues: "gcc [...] -o .libs/") has the same cause, apart from the fact that it's libtool's fault again: -o must name a target file, not a directory. aspell contains libtool 1.3c, which is old. Your best bet at the moment is running "libtoolize --force" in its top level directory while having a modern libtool package installed. This may well fix those bugs (or not). -- Robbe
Attachment:
signature.ng
Description: PGP signature