Summary: | sys-devel/libtool: migrate to link_all_deplibs=no | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nikoli <nikoli> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | ansla80, kredba, phajdan.jr |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 497956 |
Description
Nikoli
2014-01-17 19:04:26 UTC
(In reply to Nikoli from comment #0) > Default LDFLAGS have '-Wl,--as-needed', but libtool still has > link_all_deplibs=unknown: causes overlinking and conflicts with --as-needed > feature. Alt Linux and Debian have link_all_deplibs=no for years, so it is > possible to use patches from them if some packages will fail to build. umm, no, --as-needed is respected w/ ELT-patches/as-needed/ http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/ELT-patches/as-needed/ setting/forcing link_all_deplibs=no would kill the purpose of keeping .la files for .a static archives that don't have pkg-config files for the job, AFAIK so there is nothing left to do, except maybe calling 'elibtoolize' on specific packages that show such overlinking When i opened this bug, i thought link_all_deplibs=no would affect only '/usr/bin/*-config --libs' behaviour and not '/usr/bin/*-config --static-libs'. Are you sure it affects static libs usage? (In reply to Nikoli from comment #2) > When i opened this bug, i thought link_all_deplibs=no would affect only > '/usr/bin/*-config --libs' behaviour and not '/usr/bin/*-config > --static-libs'. those *-config's are each different and not a standard of anykind. if a package has both, pkg-config files and a *-config then preferably the foo-config should be only a wrapper to pkg-config, which is the case eg. in xine-lib > Are you sure it affects static libs usage? i'm pretty sure it's the kludge that tells libtool if all of certain package's libfoo.la's dependency_libs='-lfoobar -lbarfoo -lmorelibs -lfoofoofoo' should be pulled in or not. we keep *.la files for packages that install static archive (.a) if they don't have a pkg-config file that could provide Libs.private: and rely on the behavior that dependency_libs= value will get pulled in when building a package that uses the static archive and is a autotools+libtool based build system so if we'd set it to =no, then we could say byebye to that fallback. however if it's okay to kill that fallback, then it means modifying prune_libtool_files to drop *.la files even if there are no valid pkg-config files. some bugs would likely surface from that, but mainly, makes building out-of-portage projects harder and the ELT as-needed patch that is required to go to each package's ltmain.sh to make -Wl,--as-needed to work, is still required even if link_all_deplibs= is set to no heck, the whole ELT patch is *from* Debian re: http://bugs.debian.org/347650 so setting it to =no doesn't solve anything because we have -Wl,--as-needed by default which already drops unnecessary libraries libtool might bring in so setting it to =no would only be bothersome for static linking maybe i'm missing something, if so, what? well, lets wait for someone else to chip in too, i'll reopen this for now. > Andrei Slavoiu 2014-03-06 23:34:54 EET > Blocks: 503592 OK, reclosing before people start to use this as random tracker for overlinking issues: Gentoo keeps .la files for packages that have no alternatives ways for getting library information for .a static archives like pkg-config files with Libs.private: As in, prune_libtool_files is purposely designed to keep them Setting this to 'no' would break that scenario, so unless we want to always remove .la files, even when .a has no other way of getting the libraries... Solution 1: Use Gentoo default LDFLAGS, -Wl,--as-needed as our libtool is designed to parse it in correct order: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/ELT-patches/as-needed/2.4.2?view=markup Solution 2: Use the new GNU gold linker and newest possible binutils available for strict linker |