[csw-maintainers] zlib package in /testing

James Lee james at opencsw.org
Mon Apr 6 16:34:50 CEST 2009


On 06/04/09, 13:35:24, "Roger Håkansson" <hson at opencsw.org> wrote regarding
Re: [csw-maintainers] zlib package in /testing:

> > It's not a "problem" but if it's the result of the build system it
> > suggests we are generally making settings with no thought.  The
> > current batch of odd RPATHs only causes the link loader to look for
> > a directory that doesn't exist, but this is less wasted effort than
> > what happens with $ISALIST which typically looks at all the 64 bit
> > locations before finding that matching 32 lib.

> $ISALIST doesn't just expand to 64bit, you have optimized 32bit versions
> (sparcv8plus, sparcv8plus+vis...) as well?

It expands to the isalist.  It tries all in order but if it's a 32 bit
prog there is never a valid match in the 64s, then it runs through the
32s until the match, or not in the case of this first non CSW lib:

$ truss /opt/csw/bin/gsc
execve("/opt/csw/bin/gsc", 0xFFBEFBDC, 0xFFBEFBE4)  argc = 1
resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
open("/var/ld/ld.config", O_RDONLY)             Err#2 ENOENT
sysinfo(514, "sparcv9+vis2 sparcv9+vis sparcv9 sparcv8plus+vis
sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc", 257) = 98
stat("/opt/csw/lib/sparcv9+vis2/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv9+vis/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv9/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv8plus+vis/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv8plus/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv8/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv8-fsmuld/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparcv7/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/sparc/libc.so.1", 0xFFBEF488) Err#2 ENOENT
stat("/opt/csw/lib/libc.so.1", 0xFFBEF488)      Err#2 ENOENT
stat("/usr/lib/libc.so.1", 0xFFBEF488)          = 0
resolvepath("/usr/lib/libc.so.1", "/usr/lib/libc.so.1", 1023) = 18
open("/usr/lib/libc.so.1", O_RDONLY)            = 3
...

Lots of Err#2


> Even though I've only been a maintainer for a few months, my
> understanding (from http://opencsw.org/standards/pkg-walkthrough as an
> example) was that LD_OPTIONS was a preferred setting when building
> packages. So all packages I've built (either using gar or manually) have
> LD_OPTIONS set which means RPATH/RUNPATH have been set to
> /opt/csw/lib/$ISALIST:/opt/csw/lib whatever they need.

> If LD_OPTIONS shouldn't be used, or should only contain what's needed
> for a particular package, it should be communicated more clearly.

Once built a package doesn't know how it was built so if it works
use it.

LD_OPTIONS overrides all so is powerful.  Like all powerful weapons
use with caution.

$ man ld
...
     LD_OPTIONS
           A default set of options to ld. LD_OPTIONS  is  inter-
           preted  by ld just as though its value had been placed
           on the command line, immediately  following  the  name
           used to invoke ld, as in:

           ld $LD_OPTIONS ... other-arguments ...


> To reiterate my question:
> Is there any actual harm (disregarding the fact that the link loader
> might have to traverse /opt/csw/lib/$ISALIST:/opt/csw/lib without
> finding any match) having RPATH/RUNPATH set?

No, well it's actual but trivial.


> If not, it is only when a package doesn't use any libs at all from
> /opt/csw/lib, when RPATH/RUNPATH should be changed from the default.

Correct, as is the case with zlib.

> If package A is linked to a lib i package B (both CSW packages) and A i
> packaged with RPATH/RUNPATH set to only /opt/csw/lib, any future
> releases of B which contain optimized libraries won't be used until A is
> repackaged with RPATH/RUNPATH set to /opt/csw/lib/$ISALIST:/opt/csw/lib

Correct.  Add $ISALIST in, unless you know it won't be needed.


> And if there is a longer dependency list (A->B->C-D where D is the one
> with optimized libs) it creates much more work for the maintainer of A
> (he must check every lib in the dependency path to see if there are any
> optimized libs).

D is governed by the RPATH of C.  C by B.



James.



More information about the maintainers mailing list