Re: [aur-general] LDFLAGS question
On Wed, Nov 25, 2009 at 18:58, bardo <ilbardo@gmail.com> wrote:
Hi all. Recently I've been having fun with the latest pulseaudio quirk: it doesn't build because of the --as-needed flag in linking. I don't understand linking in depth, but as I understood it there's some dependency cycle that gets triggered by the aforementioned ld flag. However this doesn't happen when building in a chroot, where the package builds fine.
It isn't the only package where it happens, and I have a handful of questions about the correct way to handle this.
1. If something like this happens, is it an upstream bug? 2. If it builds fine in a chroot there's obviously a software that triggers the bug, does it mean I am missing a dependency? 3. If a package builds inside a chroot but not outside, should it be changed in such a way that it builds everywhere regardless of the changes that are to be made? Or should it be left as it is, and related bugs closed with "build it in a chroot"? 4. What does the absence of the ld flag imply in practical terms? Is it just a "nice to have" or has it some real implications?
Hello bardo, 1.) Depends on whether they see it as such :p Some upstreams get all annoyed and tag the bug as WONTFIX. Others care about it and take a look into it. I would file it upstream though, just in case. Also, check the Gentoo bug reports, both closed and open, for your problem -- Gentoo has lately been trying to resolve all --as-needed compile issues. 2.) Probably not missing a dependency so much as revealing a flaw in how the software is built (or the linker itself). --as-needed affects how binaries link in other stuff, a certain package may trigger the problem. 3.) I would say, personally, make it build the same everywhere. Do put a comment in the PKGBUILD though, for future reference by others 4.) --as-needed reduces some of the library dependencies of binaries, and also speeds up the dynamic linking step -- applications start faster. Therefore, it's nice to have, but can be removed if it presents problems (as it does every now and again). And lastly, please filter --as-needed in a sane way instead of exporting LDFLAGS :P I like the following three-line solution to filter all variants of --as-needed: LDFLAGS="${LDFLAGS//-Wl,--as-needed}" LDFLAGS="${LDFLAGS//,--as-needed}" export LDFLAGS="${LDFLAGS//--as-needed}" Again, please tag that block with a comment about the failure and that it doesn't fail in a clean chroot or whatever :) Hope that helps, -- Ranguvar [Devin Cofer]
participants (1)
-
Ranguvar