Re: CVS commit: pkgsrc/graphics/xzgv

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

On 12/30/2011 3:55 PM, Joerg Sonnenberger wrote:
> On Fri, Dec 16, 2011 at 02:29:16PM +0000, David Holland wrote:
>> On Fri, Dec 16, 2011 at 10:37:07AM +0100, John Marino wrote:
>>  > > Do I understand correctly:
>>
>>  > > The package is using functions from libm and libX11 directly, but
>>  > > is not linking against either.
>>  > > 
>>  > > Previously (before ld 2.22), this worked because the libraries
>>  > > are pulled indirectly.
>>  > > ld 2.22 changed this behaviour.
>>  > > 
>>  > > If that's the case, your changes are fine with me.
>>  > 
>>  > 
>>  > Yes, that's my understanding of the situation.
>>  > [...]
>>  > With the default setting however the searching of dynamic
>>  > libraries that follow it will stop with the dynamic library itself. No
>>  > DT_NEEDED links will be traversed to resolve symbols.
>>
>> That is a good thing, so let's go ahead and fix.
> 
> I disagree that it is a good thing, more importantly, it is pretty
> pointless, since the binding isn't static anyway.
> 
>> (My concern from an implementation standpoint though: if a
>> corresponding change is not also made in the dynamic linker for when
>> it re-resolves symbols at runtime, this will open the way for some
>> really weird problems.)
> 
> As I wrote earlier, the problem is that can slow down runtime symbol
> lookup, e.g. it is conter productive. It strongly looks like yet another
> attempt by the GNU folks to change the specs of ELF uniliterally.
> 
> Joerg

Assuming that the assertion that symbol lookup is slower than recursive
search is even true, one would still choose slower-but-works over
faster-but-broken.  You can't bring up speed of compilation as a problem
when the entire pkgsrc wrapper system slows down native compilation by
an order of magnitude with a package like gcc.

Again, the majority of the packages that are broken this way were not
intended to be linked recursively.  The missing libraries were masked by
the previous linker default of searching this way.

This is a non-problem.  There really aren't that many packages that need
LDFLAGS+= to work with the latest binutils.  If it were hundreds, maybe
that would be a horse of different color, but it's been only a handful
so far.  The next bulkbuild report on a current dragonfly will flush out
the rest, but I don't expect the number remaining to be overwhelming.

John