[gentoo-dev] Re: libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

On Wed, Jan 08, 2014, Rick "Zero_Chaos" Farina wrote:
> Or we could just stop randomly moving libs across the system and
> breaking things then hackmeating things back to a "working" state with
> gen_ld_script.
> 
> The whole reason for having gen_ld_script is because people wanted
> dynamic libs in / and static libs in /usr (which seems insane) and it
> broke everything (because that idea is insane).

No it's not: it makes no sense whatsoever to have static libs in /; they
can only ever be used when one is compiling software, so by definition
have /usr available. And moving a dynamic lib is perfectly fine in terms
of the system running. That's what /etc/ld.so.cache is for.

I agree that it hasn't been done brilliantly fwtw. But there is no
reason on earth not to make the change proposed until such time
as an alternative impl is put in place; it can only make /lib more
consistent.

>  Maybe we could just
> install all the libs together (either / or /usr) and stop pretending
> that what we are doing isn't wrong?

I'm still at a loss to understand why building the pkg with libdir=/lib
and then simply moving the static libs to /usr is not an option.
/usr/lib is automatically looked up by the linker, so that won't affect
builds: the only issue I can see would be a minor edit of any pkgconf
file, if libs are under a subdir, and that only affects static linking.

In no event, could not having static libs available under /lib be an
issue at startup, in stark contrast to dynamic ones. So the ld_script
approach seems really odd, no doubt a result of my ignorance. If all
else failed wrt libtool, one could easily symlink static libs under
/usr/lib to their lt install location under /lib.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)