Hi, I'm talking about the multi-language branch and about its C++ support. The specific problem below I've seen on HP-UX, but I believe its a problem for all platforms which need file_magic in its deplibs_check_method: When configuring libtool it searches for libraries the compiler adds automatically when linking a program. For g++ this includes '-lstdc++ -lgcc'. For libstdc++ there is a shared version, so that makes no real problems (well, the installers of gcc only have to remember to use --enable-shared, which surprisingly often is forgotten), but libgcc only exists as static version. Now, when linking a shared library (or a -module) libtool searches for all depence libs, and checks if they are also shared (when deplibs_check_method is file_magic), and in case only static versions are found, it drops that dependency from the linkline, but still builds a shared lib. For modules the situation is another one: if any libs are dropped, libtool does _not_ build the module, but instead creates an archive. This means, that on platforms which need file_magic no modules can be build, as at least libgcc gets dropped every time. I don't believe this was intented, but I'm asking here, how this was supposed to work, so I can help to fix that. On HP-UX I simply hacked the created libtool to not include those -lgcc's (and to not use -nostdlib for g++) and the build of KDE went mostly fine (OK, I've patched libtool to support HP-UX and g++, and that patch is finding its way to libtool-patches, but I first want to resolve this issue). I see different solutions to this: * don't include -lgcc in postdeps, but then g++ must add it, and -nostdlib can't be used. * don't include postdeps in the dependency checking, in the hope, that the libraries installed by the compiler will just work (this is unfortunately not the case for libstdc++ as its compiled without PIC) * don't include -lgcc in the dependency check, as we know, it will work even when linked into shared objects This is becoming also an issue on Solaris, as pass_all is not working correctly, because the static libstdc++ can't be linked into shared objects, and thus must be dropped, which means, that Solaris' deplibs_check_method need to become file_magic (or libstdc++ needs also stripping from the list which is checked). Hmm, I just wonder how the normal libtool handles Solaris, because there the check_method is set to pass_all. Can Solaris now link static libs into shared ones, or not? And if it can, why is libstdc++ making such problems (we just had another report of that 'Text relocation remains' error)? So again, if anybody can enlighten me on how it *should* work, we might be able to make sure, that it *does* work in that way ;) Ciao, Michael.
