FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 11-25-2009, 10:58 PM
bardo
 
Default 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?
 
Old 11-25-2009, 11:17 PM
Ranguvar
 
Default 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 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]
 
Old 11-25-2009, 11:27 PM
Allan McRae
 
Default LDFLAGS question

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
 
Old 11-25-2009, 11:35 PM
bardo
 
Default LDFLAGS question

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.html
 
Old 11-25-2009, 11:37 PM
Ranguvar
 
Default LDFLAGS question

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]
 
Old 11-26-2009, 01:51 AM
"Allan McRae"
 
Default LDFLAGS question

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
 
Old 11-26-2009, 06:46 AM
bardo
 
Default LDFLAGS question

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
 

Thread Tools




All times are GMT. The time now is 05:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org