[csw-maintainers] RPATH/ISALIST (zlib package in /testing)

[James Lee]

On 07/04/09, 07:08:54, "Roger Håkansson" <hson at opencsw.org> wrote regarding
Re: [csw-maintainers] RPATH/ISALIST (zlib package in /testing):

> > 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:
> >

> And your solution to that "problem" is?

Sun could make 32 progs use a 32 bit isalist, but this isn't "my"
problem, it's Sun's.  All I'm saying is that a good $ISALIST RPATH
causes more failed file look-ups than a bad one.


> Add all 32bit paths to RPATH/RUNPATH when building a 32bit app/lib,
> instead of just $ISALIST?

isalist expansion happens locally, that why/how it works.



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

> Parse error...

Once a package is built the package doesn't know how the package was
built so if LD_OPTIONS works to make a package that works use
LD_OPTIONS to build the package.




> My point was that LD_OPTIONS is used by default when building using gar.
> And those broken RPATH/RUNPATHs was due to a bug in gar, not what the
> maintainer might have set (or not set).

The package doesn't know how the package was built - GAR is irrelevant
to the result.  The maintainer is responsible for what is in the package.



> >> 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.

> I'm not thinking of just zlib, I'm speaking in a more general term plus
> "should" should have been "could".

"should" could have been "could".
"should" is right, but the RPATH needn't be right because the error is
trivial.


switch (person.getType())
{
    case PEDANT:
        message = "must";
        break;
    case MATHEMATICIAN:
        message = "should";
        break;
    case ENGINEER:
        message = "could";
        break;
    case ACCOUNTANT:
        message = "if it makes money";
        break;
    case BANKER:
        message = "if it makes me money";
        break;
    case TEENAGER:
        message = "yeah wotevva";
        break;



> Since we have established that its not harmful to have RPATH set even
> when its not used,

It's harmful but trivial.


> I can see more problem (as in more work for the
> maintainer in the future) with actively unsetting LD_OPTIONS than not.

Sorry I can't see why unsetting something has only been set by yourself
in the first place is more work.  In fact we should always explicitly
either set or unset such controlling environmental variables as a
matter of good practice.




James.