Re: patch for REQUIRES

["Filip Hajny" <filip%joyent.com@localhost>]

On 18. 3. 2012, at 16:39, Thomas Klausner wrote:

> On Sun, Mar 18, 2012 at 03:44:57PM +0100, Filip Hajny wrote:
>> I should have stressed out this is only the case if the said lib is normally 
>> present elsewhere in the default search path, which is not the case on 
>> NetBSD with libexpat. See partial output of ldd here (on SunOS):
>> 
>> [root@pkgbuild /tmp/pkgsrc/textproc/expat/work/.destdir]# ldd -s 
>> opt/local/bin/xmlwf 
>> 
>>   find object=libexpat.so.1; required by opt/local/bin/xmlwf
>>    search path=/opt/local/lib  (RUNPATH/RPATH from file opt/local/bin/xmlwf)
>>    trying path=/opt/local/lib/libexpat.so.1
>>    search path=/lib:/usr/lib:/opt/local/lib  (configuration default - 
>> /var/ld/ld.config)
>>    trying path=/lib/libexpat.so.1
>>    trying path=/usr/lib/libexpat.so.1
>>        libexpat.so.1 =>         /usr/lib/libexpat.so.1
>> 
>> So the natural outcome of this is that REQUIRES records libs that are not 
>> normally used/linked, just because we're in the stage-install phase still.
>> 
>> I understand now this doesn't happen on NetBSD at all, because (correct me 
>> if I'm wrong) NetBSD doesn't have a concept of a default run-time linker 
>> search path like crle on Solaris.
> 
> So can you give Solaris ldd some flags to suppress looking in the default 
> search path?
> Or would this break even worse?
> 

No, there is a -c arg that bypass config files (i.e. what crle governs), but 
that only makes ldd fall back to the fixed system default, which is 
/lib:/usr/lib. Also, turning off default search path would also exclude valid 
linked libs on that path.

I take back the comment about multimedia/ffmpeg or devel/poco - I can't 
reproduce those any more. Also, I can't seem to trigger the issue on NetBSD - 
because I can't find a match between the native lib names/versions and their 
respective pkgsrc alternatives.

I *was* able to reproduce on NetBSD when I symlinked /usr/lib/libbz2.so.1 to 
/usr/lib/libbz2.so.0, which matches the version in the archivers/bzip2; that 
made it show up in REQUIRES. (An unlikely example, but still.)

So it seems to be largely a case on Solaris, where typically many more native 
libs are present, yet the user is likely to prefer pkgsrc packages. Do you have 
concrete objections to the patch besides "works for me" or "not needed on 
NetBSD"? Should I wrap in OPSYS-based conditional?

-F