On Tue, 13 Oct 1998, Billy G. Allie wrote:
> I am running UnixWare 7.01, a System V Release 4 based system. It is
> an ELF based system with roots back to the first ELF based systems.
> It's linker does not have a -R or --rpath option. To have UnixWare's
> ld command embed the location of the shared libraries into the
> executable, you set the LD_RUN_PATH to the path(s) containing the
> libraries.
Ok.
> From the syntax of the --rpath option, it is apparent you are running
> the GNU C compiler with ELF support (an upstart, late commer in the
> world of ELF support).
Actually, while I did mention --rpath (In the context of a FreeBSD/ELF or
Linux/ELF system) I am running Solaris which uses the -R flag to tell
ld(1) where things are. -R takes prescedence over LD_RUN_PATH according
to my doc.
> You should know that the one true path of ELF support is to use the
> LD_RUN_PATH environment variable, not -R/--rpath :-> I find it much
> easier to set LD_RUN_PATH then to have configure figure out that the a
> system is running GNU C with ELF support and for that system only, use
> -R/--rpath. Check out your ld command. If it supports
> LD_LIBRARY_PATH, it probably supprorts LD_RUN_PATH. If it does, then
> use it to embed the library locations into your executable.
I'm pretty sure all ELF systems support LD_LIBRARY_PATH and LD_RUN_PATH.
Using -R/--rpath allows us to have better control of what search paths are
compiled in. Who knows what the user has LD_RUN_PATH set to. Should
configure ask them if they want to use LD_RUN_PATH as well? Should we
find all the libraries we are to link with and construct our own
-R/--rpath? For systems that don't support -R/--rpath we'll have to do
this anyway as we'll be messing with LD_RUN_PATH.
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |