Re: pkg/46478: www/curl does not compile on Solaris/sparc with compiler not configured with devel/libelf

[Jörn Clausen <joern.clausen%uni-bielefeld.de@localhost>]

The following reply was made to PR pkg/46478; it has been noted by GNATS.

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen%uni-bielefeld.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: David Holland <dholland-pbugs%NetBSD.org@localhost>, 
pkg-manager%NetBSD.org@localhost,
 gnats-admin%NetBSD.org@localhost, pkgsrc-bugs%NetBSD.org@localhost
Subject: Re: pkg/46478: www/curl does not compile on Solaris/sparc with
 compiler not configured with devel/libelf
Date: Mon, 25 Jun 2012 09:18:10 +0200

 On 24.06.12 23:00, David Holland wrote:
 >   The two copies of libelf may not be entirely compatible though. One
 >   would hardly expect them to be, especially since one was shipped by
 >   Sun using who knows what sources of who knows what antiquity.
 
 It's the system's libelf, and that should be good enough. Obviously they 
 are not compatible, and replacing the native one with a 
 who-knows-where-it-came-from version is not a good idea either.
 
 >   Sun's assembler needs to be using only Sun's libelf. Otherwise the
 >   behavior of the assembler is undefined. It is a bug in the assembler
 >   that it will randomly pick up some other libelf (not even of the right
 >   soname) but that is after all the sort of quality one expects from Sun
 >   userlands.
 
 Please keep any religious issues you might have out of this discussion.
 
 Yes, Solaris assembler has a bug, which has been reported and will 
 probably get fixed. I don't expect the fix to be backported to Solaris 
 10, though.
 
 >   The right fix, I think, is to make sure the assembler doesn't see the
 >   pkgsrc libelf.
 
 The right solution is not to use devel/libelf on Solaris at all. The 
 *only* binary, that actually uses that libelf instead of the native one 
 is "gresource" from devel/glib2. And that binary segfaults both on sparc 
 and i86. And looking at the README of devel/libelf, I don't think that 
 that library is able to fix the problem with the native libelf (large 
 file support) in the first place. Please remove the dependency of 
 devel/glib2 on devel/libelf and revert to the old workaround.
 
 -- 
   Jörn Clausen                             
joern.clausen%uni-bielefeld.de@localhost
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld