[aur-general] LDFLAGS question
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?
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
2009/11/26 Allan McRae <allan@archlinux.org>:
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.
Well, it seems to be known and documented upstream, and they don't consider it as a bug: http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg04883.htm...
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]
Ranguvar wrote:
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.
I looks like pulse-audio will link to itself and that causes issues with --as-needed. Heimdal had (has?) the same issue so had something like this in the PKGBUILD: [ -e /usr/lib/libasn1.so ] && echo "## remove old heimdal pkg first ##" && return 1 If pulse-audio only fails to build when pulse-audio is present, a line like that in the PKGBUILD will solve all problems. Or just a comment at the top like the current heimdal package: # ### Attention: remove old pkg before building - it links against itself! ### # Allan
2009/11/26 Allan McRae <allan@archlinux.org>:
I looks like pulse-audio will link to itself and that causes issues with --as-needed. Heimdal had (has?) the same issue so had something like this in the PKGBUILD:
[ -e /usr/lib/libasn1.so ] && echo "## remove old heimdal pkg first ##" && return 1
If pulse-audio only fails to build when pulse-audio is present, a line like that in the PKGBUILD will solve all problems. Or just a comment at the top like the current heimdal package:
# ### Attention: remove old pkg before building - it links against itself! ### #
Well, I like these solutions. The problem, though, kind of "solved" itself. I'm trying to build the brand new 0.9.21, and it also fails in a chroot with the same error. It doesn't make a lot of sense to me (the chroot is clean) but the errors are the same, so there must be some other package that causes this. Corrado
participants (3)
-
Allan McRae
-
bardo
-
Ranguvar