Matti Bickel posted on Wed, 17 Aug 2011 00:30:43 +0200 as excerpted: > Hi folks, > > coming back from an extended vacation I found bug #351266[1] still open. > The root cause of this install failure seems to be libtool trying to > relink php's apache module.
> So that leaves me with either: > a) remove the relink_command from libphp5.la before calling emake > install-sapi > b) modifying the libdir in libphp5.la before calling emake > install-sapi to point to $D/usr/lib/... > c) finding out why libtool decides it needs to relink at all. > > Clearly, requiring users to edit the la file by hand is no solution. > I'd be glad if somebody with more libtool knowledge can shed some light > (or point me to some docs) on why relinking is necessary here at all > and how to fix this breakage. > > [1]https://bugs.gentoo.org/show_bug.cgi?id=351266 I see flameeyes commented (once) on the bug. What I know about libtool is from a user-perspective, but nearly 100% based on what flameeyes has written on the topic in various blog posts, etc, obviously from a developer perspective in most cases. He has blogged about libtool and *.la files numerous times and I believe has a developer-focused libtool guide up. So I'd definitely recommend that direction. Whether you read the blogs first and then ping him if necessary, or ping him for more directed help first is up to you, but that's definitely where I'd start looking, for sure. ... Meanwhile, purely from my gentoo user aka gentoo-based system sysadmin perspective, I've noted more and more gentoo packages with the USE=static- libs flag controlling both the generation of the *.a libs and their *.la file counterparts, thus gradually reducing the *.la file pain-points for many users, tho if removal order isn't maintained, it can cause more pain temporarily, as *.la files from other packages may well reference those removed. Two other related factors are worth noting in this regard: 1) Portage's FEATURES=fixlafiles (and the lafilefixer package/script, tho without FEATURES=unmerge-orphans set it can be problematic if run manually due to the fact that it alters files behind portage's back) can be VERY helpful in this regard. Again, user perspective so I don't know if that might be the difference you're seeing between the behavior on your systems and that of the bug reporter's, but the general idea is to fix *.la files to point to the libraries directly, instead of to other *.la files, thus avoiding issues when lower level depencencies remove their *.la files in the first place (with the feature) or fixing the problem once it occurs (with the script run manually). 2) It remains a bit of a bold step, suitable mainly for advanced users who can trace resulting issues and revert the policy for individual packages (using /etc/portage/env/*/* files, for instance), but for many of the users who aren't aware of any specific reason to have static libraries available on their system at all, setting INSTALL_MASK (and PKG_INSTALL_MASK if appropriate) to include *.la, thus eliminating the problem files entirely, can be a viable option, *WITH*ONE*MAJOR*EXCEPTION, the libtool package itself. Here, I have the general (PKG_)INSTALL_MASK="*.la" , but empty the variable(s) in /etc/portage/env/sys-devel/libtool , so the libtool package's own *.la files aren't touched. (Certain build systems' config step fails if they can't find libtool's own *.la files so those must remain, but they are the only ones left on my system! =:^) So by all means either read up on flameeyes' libtool blog posts or contact him, but it may well be possible to simply eliminate that problem *.la file, at least for those without USE=static-libs set for its containing package, entirely, at the package level for you as a developer, and/or at the system level for gentoo users aka gentoo-based- system sysadmins, like me, and possibly the user reporting the bug in question, if they aren't aware of any specific reason why the package containing that *.la needs built with static-libs support at all. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
