On Wed, Nov 25, 2009 at 19:27, Allan McRae <allan@archlinux.org> wrote:
bardo 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?
It is probably an addition dep (optional) that is being detected on your system and causing the failure. Personally, I would build in a chroot and ignore the issue. There are plenty of packages that should only be built in a chroot due to issues similar to this and _ALL_ packages should be built in one anyway.
Allan
Shouldn't a PKGBUILD try to cover all potential normal Arch setups, though? If it is known that a package conflicts with the build, and it can't be traced to the individual package so it can be added in conflicts() (or we may not want it there), then I think the PKGBUILD should be modified to work in all common scenarios. At worst case though, IMO, the appropriate lines to filter --as-needed should be present except commented out, with a comment explaining to uncomment them if the user experiences build failure. -- Ranguvar [Devin Cofer]