All, portage bans installing *.a and *.la files in /lib*. This forces us to split up the library installation locations by allowing upstream build systems to install their libraries in /usr/lib* then manually moving the shared libraries to /lib*. This confuses the linker, which led to bug #4411. The method we use to get around that is buggy also, see bug #487696. Because of this, I am requesting that you remove the ban on installing these files in/lib* so we can completely get rid of gen_usr_lcscript and use upstream build systems to install the libraries where we want them to be installed. Thanks, William
Do you happen to have an example ebuild that does this? (Preferably non-critical package.)
You can see the split in action with any package without harming your system. For example, take the ncurses package. If you emerge it with the static-libs use flag turned on then run "qlist ncurses | grep -i /lib", you will see that the shared libraries are installed in /lib*, but the static libraries are in /usr/lib* All I'm saying in this bug is that portage forces static libraries to be in /usr/lib* but shouldn't. Once the ban is removed, we can go through the packages with gen_usr_ldscript and figure out whether the libraries belong in /lib* or /usr/lib* and move all of them to the appropriate place through the packages build systems. Thanks, William
i don't think we want .la or .a files in / still. the point of not using gen_usr_ldscript is to avoid using /lib at all. the libs would simply live in /usr/lib like normal.
(In reply to SpanKY from comment #3) > i don't think we want .la or .a files in / still. the point of not using > gen_usr_ldscript is to avoid using /lib at all. the libs would simply live > in /usr/lib like normal. The *BSD world needs libraries of some packages in /lib, but I think we should do that with the package build system, so for example, in ncurses on *BSD we would pass --libdir=/$(get_libdir) to the econf call. If we allow that, I think we can completely get rid of gen_usr_ldscript and stop splitting up where we install the libs.
(In reply to William Hubbs from comment #4) i don't think so. the point of having a split /usr is so that you can have a tiny / with a large /usr. by installing .a & .la files into /, you quickly increase the overhead. we install shared libs into / because we want to support a split /usr. we have gen_usr_ldscript because we need the linking to still work when static archives exist. if support for a split /usr is disabled on the system, then you no longer install into / which means the rest is irrelevant. the answer isn't to install more junk into / all the time. as to your example, you have two choices: (1) run configure with --libdir=/lib (2) run `gen_usr_ldscript -a <lib list>` the former impacts everyone. the latter impacts only people with split /usr. it's the same amount of code, except the latter is cleaner for people not using a split /usr.
@William: Could you respond or close the bug?
(In reply to SpanKY from comment #5) > (In reply to William Hubbs from comment #4) > > i don't think so. the point of having a split /usr is so that you can have > a tiny / with a large /usr. by installing .a & .la files into /, you > quickly increase the overhead. > > we install shared libs into / because we want to support a split /usr. we > have gen_usr_ldscript because we need the linking to still work when static > archives exist. if support for a split /usr is disabled on the system, then > you no longer install into / which means the rest is irrelevant. the answer > isn't to install more junk into / all the time. > > as to your example, you have two choices: > (1) run configure with --libdir=/lib If I do this with a package, portage will refuse to allow it, and it shouldn't since this is the upstream recommended way of installing libraries in /lib. That's the only thing I'm saying with this bug.
(In reply to William Hubbs from comment #7) but you end up satisfying no one. either you want to support a split /usr which means small / footprint, or you don't which means --libdir=/lib isn't going to be used anyways. in my experience, gen_usr_ldscript has kept things a lot simpler than they otherwise might be.
