Thread: Re: Installation Report for powerpc-apple-netbsdelf1.5

Henry B. Hotz writes:

> Shouldn't there be an option to disable shared libraries altogether?

The promised land for all of this is GNU libtool, which offers all these
little options. I brought up the rpath thing a while ago, and while it
might look the same on a lot of platforms, it's potentially just another
source of problems when implemented manually. The LD_RUN_PATH does the
same thing on many platforms; perhaps we should mention it somewhere.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

At 11:58 PM +0200 8/4/00, Peter Eisentraut wrote:
>Henry B. Hotz writes:
>
> > Shouldn't there be an option to disable shared libraries altogether?
>
>The promised land for all of this is GNU libtool, which offers all these
>little options. I brought up the rpath thing a while ago, and while it
>might look the same on a lot of platforms, it's potentially just another
>source of problems when implemented manually. The LD_RUN_PATH does the
>same thing on many platforms; perhaps we should mention it somewhere.

NetBSD has a FAQ on all the arguments about what ELF does/doesn't, 
should/shouldn't do.  What I can remember sounded pretty unresolved, 
with a clear disconnect between the design intent for ELF and actual 
current practice.

I think what you're supposed to do in NetBSD is what was said earlier 
(-Wl,-R/usr/whatever/lib).  Sounds like that conflicts with a lot of 
people's beliefs about how to do it on a lot of other platforms 
though.  It also breaks the "try the regression tests before 
installing" feature.

*sigh*


Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

> I think what you're supposed to do in NetBSD is what was said earlier
> (-Wl,-R/usr/whatever/lib).  Sounds like that conflicts with a lot of
> people's beliefs about how to do it on a lot of other platforms
> though.  It also breaks the "try the regression tests before
> installing" feature.

Not necessarily, since you can override the rpath setting with
LD_LIBRARY_PATH (at least on Linux and presumably other gnu-capable
systems).

However, the link set will fail if the path to the directory does not
exist (again, at least for gcc/g++ on Linux and Solaris). That may not
be a problem for most package builders (since things will go in a
standard place) but will cause problems for installing into standalone
areas. Especially for, as you point out, testing before installation.
                    - Thomas

At 2:20 AM +0000 8/5/00, Thomas Lockhart wrote:
> > I think what you're supposed to do in NetBSD is what was said earlier
> > (-Wl,-R/usr/whatever/lib).  Sounds like that conflicts with a lot of
> > people's beliefs about how to do it on a lot of other platforms
> > though.  It also breaks the "try the regression tests before
> > installing" feature.
>
>Not necessarily, since you can override the rpath setting with
>LD_LIBRARY_PATH (at least on Linux and presumably other gnu-capable
>systems).

Ah, I found it!  It's LD_RUN_PATH on this platform (NetBSD/macppc). 
At least we do have the (backward IMHO) Solaris-style workaround. 
NetBSD/mac68k is still using xcoff so they have a /etc/ld.so.conf 
file.  That works much better for this situation.

FWIW the Linux crowd (MkLinux and LinuxPPC) are also using SysV/ELF 
binaries while AIX/Darwin/MacOS X are using xcoff.  I'm really not 
sure that ELF is the step forward it's cracked up to be.  I guess the 
Linux folks are no happier with the situation.

It would appear that the correct thing to do for NetBSD/ELF is the 
-W-R stuff and then set LD_RUN_PATH for the preinstall regression 
tests.  Sorry if that makes the configure setup more complex.


Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu