Re: CVS commit: pkgsrc/graphics/xzgv

[John Marino <netbsd%marino.st@localhost>]

On 12/31/2011 3:03 PM, Joerg Sonnenberger wrote:
> On Sat, Dec 31, 2011 at 02:07:15PM +0100, John Marino wrote:
>> On 12/31/2011 1:51 PM, Joerg Sonnenberger wrote:
>>>> What's the real impact?  slightly slower startup time?  Is it even
>>>> perceptible?
>>>
>>> The important part is that it is a *useless* change. There is absolute
>>> nothing wrong with indirect symbols.
>>
>> The magnitude of the impact of the change is relevant.  Obviously these
>> last two sentences are a matter of opinion, and yours differs from the
>> authors of binutils.  If the practical impact of eliminating indirect
>> symbols is zero, but lets packages remain buildable on new binutils
>> linkers, then why crusade against it?
> 
> I have no idea how the binutils maintainers justify changing the
> semantics of ELF. Given that Linux has in the past silently changed the
> platform ABI on i386, I am not surprised by such moves. So far, I have
> seen zero *advantage* of eliminating indirect symbol usage. I don't
> count working around broken GNU tools as justification. It can
> negatively impact performance *for everyone else*. I'd even argue that
> it is conter productive to the useful DT_NEEDED eliminated of unused
> libraries. *That* in combination with using indirect symbols as
> implemented by the dynamic linker anyway, can significantly cut down the
> size of the symbol graph.
> 
>>>> Otherwise you're basically advocating that all platforms of pkgsrc
>>>> either stick to binutils 2.21 or less forever, or that they patch
>>>> gold/ld version 2.22+ to behave as before.  I don't think such an
>>>> artificial restriction is desirable.
>>>
>>> Somehow I don't see that as a strict requirement. Heck, I would consider
>>> it worth filling a bug report in binutils...
>>
>> Considering big Linux distributions are adapting to this new behavior, I
>> doubt any such PR would result in something other than "wontfix".
> 
> So we already found out that the sane behavior can be restored by just
> adding the right ld option in the wrappers. Meaning, we can essentially
> ignore Linux distros breaking the world again. I don't mind adding this
> as yet another item of stupid Linuxism. I think the follow email nicely
> sums up the position from that camp:
> 
> http://www.cygwin.com/ml/libc-alpha/2008-12/msg00068.html
> 
> Joerg


I really don't want to get caught up in all these wars.  I just want to
fix packages that are currently broken on DragonFly.

I'm perfectly happy to wrap "LDFLAGS+=..." inside '.if ${OPSYS} ==
"DragonFly"' conditionals if that is what it takes to get the packages
to build again without controversy.

If the wrappers are going to be modified to force newer linkers to
behave like older linkers then that would "fix" this issue.  I suspect
that the new linker is actually uncovering mistakes in several package
vendor makefiles, so modifying the wrappers would also lose this benefit.

The impact of the linker change is not nearly as dramatic as it's being
portrayed by some.  However, rather than get dragged further into an
emotional (rather than technical) debate about the wisdom of the change,
just come up with a solution that doesn't involve leaving packages
broken on DragonFly.

John