Re: Linking against indirect dependencies
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu szombat 29 mjus 2004 12:41 dtummal ezt rta: On May 28, 2004, Szombathelyi Gyrgy [EMAIL PROTECTED] wrote: AFAIK it's possible to link in libdep to libfoo if libdep is static Depends on the platform. Some combinations of OSs, ABIs and hardware architectures don't allow non-PIC in shared libraries. Yes, several of the platforms that don't support this are GNU/Linux ports. Try this on x86_64-linux-gnu, for example. It won't work, unless you somehow arrange for libdep.o to not contain any relocations that aren't PIC. Ok, as I see, libtool cannot solve this, but as I researched further, libtool doesn't need to solve it. Newer GNU 'ld' has the flag --as-needed, which does exactly the thing I wanted. The only problem from the libtool side is that if I specify LDFLAGS=-Wl,--as-needed, libtool will append these flags after dependency_libs, so the option will be useless. I attached a patch which puts $compiler_flags before any dependencies. Is this patch acceptable? Bye, Gyrgy lt.diff.gz Description: GNU Zip compressed data ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On May 28, 2004, Szombathelyi Gyrgy [EMAIL PROTECTED] wrote: AFAIK it's possible to link in libdep to libfoo if libdep is static Depends on the platform. Some combinations of OSs, ABIs and hardware architectures don't allow non-PIC in shared libraries. Yes, several of the platforms that don't support this are GNU/Linux ports. Try this on x86_64-linux-gnu, for example. It won't work, unless you somehow arrange for libdep.o to not contain any relocations that aren't PIC. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
RE: Linking against indirect dependencies
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alexandre Oliva On May 28, 2004, Szombathelyi Gyrgy [EMAIL PROTECTED] wrote: AFAIK it's possible to link in libdep to libfoo if libdep is static Depends on the platform. Some combinations of OSs, ABIs and hardware architectures don't allow non-PIC in shared libraries. Yes, several of the platforms that don't support this are GNU/Linux ports. Try this on x86_64-linux-gnu, for example. It won't work, unless you somehow arrange for libdep.o to not contain any relocations that aren't PIC. I come across this situation from time to time, and I've had to just manually create an archive of PIC object files so that it can be linked into the shared library. Generally a PIC static library is usable in static executables as well, as long as *something* (e.g. libc) was dynamically linked (thus forcing the PLT or whatever dynamic init code to be present). -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
Hello! Bob Friesenhahn írta: It is not an easy task to intuit which systems require the full linkage list and which will work properly with an abbreviated list. Even older Linux versions require the full linkage list (or several copies thereof!). A further problem is that libtool doesn't reliably know if a static or shared library will be used by the system linker. If it guesses wrong and a static library is used, then everything breaks since static libraries don't support dependencies. And what about adding an option to libtool, like --disable-indirect-dependencies (should be shorter, I think), with a correspondig ./configure option, so a brave man can exploit the power of his choosen platform. Maybe make it default on some platforms. Users of this options should be package maintainers, who have greater experience in compiling software and can decide if this option is safely usable. Bye, György ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On May 26, 2004, Bob Friesenhahn [EMAIL PROTECTED] wrote: It also depends on libtool being 100% accurate in determining if a library is a static library or a shared library since static libraries don't support library dependencies. And there's another problem. When libtool passes -ldependency in the command line, the linker will look for libdependency in the directories where it looks for libraries (-L). If libdependency is only brought in by another shared library that has it in DT_RPATH, libdependency will be looked for in the --rpath-link search path, and it will have to be a shared library, i.e., static libs will be ignored. Now consider the following scenario: - libfoo.la is linked with libdep.la, but libdep.la was PIC and static-only. Both are installed. - libdep is rebuilt as both static and shared, and reinstalled. - program links with libfoo.la, using symbols from libdep.la that weren't brought into libfoo.la - libtool sees libdep.la is available as a shared lib, so it drops it from the link command. Link fails because libfoo.so doesn't bring in libdep.a. The only way to avoid this sort of problem would be to annotate libfoo.la with some indication that libdep.la was static-only at the time libfoo.la was created, as opposed to attempting to detect what kind of lib it is at the time libfoo.la is linked into something else. I.e., for libraries that are built as both dynamic and static, libtool would have to keep two dependency lists, one for the dynamic version, and one for the static version, such that the dynamic dependency list doesn't contain dependencies that are shared libraries. I think it can be made to work, but it's going to be a significant amount of work, and there are probably some additional problems that I haven't thought of. Risky... -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
Friday 28 May 2004 09:27 dátummal ezt írta: And there's another problem. When libtool passes -ldependency in the command line, the linker will look for libdependency in the directories where it looks for libraries (-L). If libdependency is only brought in by another shared library that has it in DT_RPATH, libdependency will be looked for in the --rpath-link search path, and it will have to be a shared library, i.e., static libs will be ignored. Now consider the following scenario: - libfoo.la is linked with libdep.la, but libdep.la was PIC and static-only. Both are installed. - libdep is rebuilt as both static and shared, and reinstalled. - program links with libfoo.la, using symbols from libdep.la that weren't brought into libfoo.la - libtool sees libdep.la is available as a shared lib, so it drops it from the link command. Link fails because libfoo.so doesn't bring in libdep.a. AFAIK it's possible to link in libdep to libfoo if libdep is static (at least I'm succeeded with a small test case), and then the program not need to link with libdep. I tried: gcc -c libdep.c gcc -c libfoo.c ar q libdep.a libdep.o ld libfoo.o -o libfoo.so -shared -ldep -L. gcc prog.c -o prog -lfoo -L. Or am I wrong? Bye, György Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
Hello! Yes, I read the thread. I agree that libtool should perform the optimization you want but I don't see it as something that is a show-stopper. I agree that it isn't a show-stopper, but it would be very nice if libtool could handle this. Can someone add this 'feature' to the libtool TODO list? Bye, György ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Wed, 26 May 2004, Szombathelyi György wrote: Yes, I read the thread. I agree that libtool should perform the optimization you want but I don't see it as something that is a show-stopper. I agree that it isn't a show-stopper, but it would be very nice if libtool could handle this. Can someone add this 'feature' to the libtool TODO list? If it could be made to work reliably, then why not? Unfortunately, it seems to be based on a library nirvana where every other library has been linked just right so that it provides the correct embedded dependencies. It also depends on libtool being 100% accurate in determining if a library is a static library or a shared library since static libraries don't support library dependencies. Users will be very unhappy if the applications or libraries they link using libtool don't work at all. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
Hi! Here's another description of the problem, so I'm not the only one who think that a solution is needed. They mention pkg-config, not libtool, so maybe a fix required in pkg-config, too, but as I read the TODO in libtool, there are common goals in these projects, so the root of the problem seems the same. http://www.autopackage.org/docs/devguide/ch07s03.html Bye, György ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Wed, 2004-05-26 at 08:07 +0200, Szombathelyi Gyrgy wrote: Yes, I read the thread. I agree that libtool should perform the optimization you want but I don't see it as something that is a show-stopper. I agree that it isn't a show-stopper, but it would be very nice if libtool could handle this. Can someone add this 'feature' to the libtool TODO list? Patch was written and rejected; The Debian libtool packages include it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Tue, May 25, 2004 at 11:37:38AM +0200, Szombathelyi_GyXrgy wrote: On Mon, 24 May 2004, Albert Chin wrote: dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well, like -pthread. BTW, is it _really_ a problem to link against everything in dependency_libs? Indirectly, this is going to happen anyway even if libtool doesn't do this. Yes, it's a problem, when someone wants to package his application/library - most times a dependency hell will start. Did you see the thread I linked above? http://lists.kde.org/?l=kde-core-develm=108534182408921w=2 Yes, I read the thread. I agree that libtool should perform the optimization you want but I don't see it as something that is a show-stopper. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Mon, 24 May 2004, Albert Chin wrote: Of course the correct answer is that not linking against indirect dependencies is non-portable. Certainly Microsoft Windows DLLs require full linkage, and I believe/suspect that AIX does as well. I don't see it that way. If a backend optimization can be done for a specific platform, why not? If we lose nothing, I don't see why libtool should not do it. The solution is still portable, as far as libtool is concerned. Such a change wouldn't change any of the cross-platform functionality libtool provides. It is not an easy task to intuit which systems require the full linkage list and which will work properly with an abbreviated list. Even older Linux versions require the full linkage list (or several copies thereof!). A further problem is that libtool doesn't reliably know if a static or shared library will be used by the system linker. If it guesses wrong and a static library is used, then everything breaks since static libraries don't support dependencies. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Mon, May 24, 2004 at 08:19:00AM +0200, Szombathelyi Gy?rgy wrote: I've just curious if is it possible _not_ to link a program/lib against its indirect dependencies. I mean if libC is linked against libB and libB is against libA then libtool will link libC against libA, which is not neccessary in most situations (at least not on Linux, but I guess not in most ELF platforms). What I've discovered is that libtool always links against all the depencency_libs in the .la file. Here's a thread about this issue in KDE: http://lists.kde.org/?l=kde-core-develm=108534182408921w=2 dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well, like -pthread. BTW, is it _really_ a problem to link against everything in dependency_libs? Indirectly, this is going to happen anyway even if libtool doesn't do this. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Mon, 24 May 2004, Albert Chin wrote: On Mon, May 24, 2004 at 08:19:00AM +0200, Szombathelyi Gy?rgy wrote: I've just curious if is it possible _not_ to link a program/lib against its indirect dependencies. I mean if libC is linked against libB and libB is against libA then libtool will link libC against libA, which is not neccessary in most situations (at least not on Linux, but I guess not in most ELF platforms). What I've discovered is that libtool always links against all the depencency_libs in the .la file. Here's a thread about this issue in KDE: http://lists.kde.org/?l=kde-core-develm=108534182408921w=2 dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well, like -pthread. BTW, is it _really_ a problem to link against everything in dependency_libs? Indirectly, this is going to happen anyway even if libtool doesn't do this. Of course the correct answer is that not linking against indirect dependencies is non-portable. Certainly Microsoft Windows DLLs require full linkage, and I believe/suspect that AIX does as well. Libtool always chooses the most portable approach and does not encourage developers to use non-portable platform-specific approaches. If libtool encouraged developers to use non-portable platform-specific techniques, then it would be dealing a blow to the goal of supporting portable software. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Mon, May 24, 2004 at 07:32:01PM -0500, Bob Friesenhahn wrote: On Mon, 24 May 2004, Albert Chin wrote: On Mon, May 24, 2004 at 08:19:00AM +0200, Szombathelyi Gy?rgy wrote: I've just curious if is it possible _not_ to link a program/lib against its indirect dependencies. I mean if libC is linked against libB and libB is against libA then libtool will link libC against libA, which is not neccessary in most situations (at least not on Linux, but I guess not in most ELF platforms). What I've discovered is that libtool always links against all the depencency_libs in the .la file. Here's a thread about this issue in KDE: http://lists.kde.org/?l=kde-core-develm=108534182408921w=2 dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well, like -pthread. BTW, is it _really_ a problem to link against everything in dependency_libs? Indirectly, this is going to happen anyway even if libtool doesn't do this. Of course the correct answer is that not linking against indirect dependencies is non-portable. Certainly Microsoft Windows DLLs require full linkage, and I believe/suspect that AIX does as well. I don't see it that way. If a backend optimization can be done for a specific platform, why not? If we lose nothing, I don't see why libtool should not do it. The solution is still portable, as far as libtool is concerned. Such a change wouldn't change any of the cross-platform functionality libtool provides. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
