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 ;-)
