[gentoo-dev] Relinking fun with libtool

[gentoo-dev] Relinking fun with libtool

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

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. I'm not entirely sure what causes this (as
my system doesn't relink the library), but more importantly I failed to
find information on what's the best way to deal with this situation. So
far, every google hit I've found suggested that just going ahead w/o
relinking worked fine, which also seems to be the case in the referenced
bug.

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've not found other ebuilds dealing with relinking, so is this me just
misunderstanding how libtool works or an issue with php's build system?
I'm quite at a loss here. 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: Relinking fun with libtool

[Duncan]

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

Re: [gentoo-dev] Re: Relinking fun with libtool

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Wed, 17 Aug 2011 07:25:22 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> 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

Uhm, the failure is in src_install.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]