[aur-general] LDFLAGS question

[Ranguvar]

On Wed, Nov 25, 2009 at 19:27, Allan McRae <allan at 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]