ld's RPATH versus gcc's

[Chris McCraw <fool@cs.utexas.edu>]

hi there,

i'm hoping you folks can shed some light on a situation i'm trying to cope
with.

environment:
solaris 2.9/ultrasparc
gcc version 3.4.3, compiled with gcc and gnu binutils (v 3.3.4/2.13.2.1)
gcc uses gnu that ld/as.
no /var/ld/ld.config (in case that matters)

in my gcc specs file extra libdirs are specified for linking in the *link
section:
	-R /lusr/lib -R /lusr/gnome2/lib

i rename the *link section removing the -R's above since i do not want
to use shared libs in there, by passing my own specs file with
	gcc -specs /u/fool/specs

and verify that gcc is applying my change with gcc -v:

  Reading specs from /path/to/gcc3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs
  Reading specs from /u/fool/specs
  rename spec link to old_link
(and in my specs file there is/must be a new link, since programs still
link a-ok with it!)

so far, so good.

i do my linking with gcc (well, technically, libtool does it for me, but
still uses gcc, and still with "-specs /u/fool/specs"), and out pops a
binary.  unfortunately that binary has an RPATH (examined with solaris'
"ldd -s" and confirmed with a binary editor) that contains all the
directories in gcc's specs file, despite my specs file specifying not to
use them.

so my question is, how can i prevent this from happening?  editing the specs
file or building a private install of gcc that never included those dirs
in its specs file is an obvious answer but not terribly useful in my
environment--i rely on a compiler used by others which requires those
RPATH additions for normal operation, and my build is taking weeks (all
of KDE) during which it will be in use by said others.

i have experimented a bit with ld -nostdlib but i haven't gotten very far
with it (ie can't link a hello world).  to complicate matters on this front,
my resulting binaries must run on a range of ultrasparcs, and most
binaries show a link like this:

        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

whose path varies from machine type to machine type (ie:

        /usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
)

other things i've tried include attacking it from the ld.so.1 end via
various env vars.  LD_LIBRARY_PATH works but breaks other applications
which want the "standard" version of libs i've built (libpng for instance),
so it is not a viable solution.  LD_NOCONFIG seems like exactly what i
want, but i can find no evidence that it actually works in my
experimentation.  creating a /var/ld/ld.config with just my directories
in it also fails for at least gnu-ld-linked applications and is anyway
not going to work in my environment.

a real kludge that "solves" my problem is to change the RPATH in the
binary with a binary editor.  right now it's my best solution (munge
/lusr/lib to /lasr/lib and no libs are found there) but surely there's
some better way.

here's hoping that someone has been down this road before and can enlighten
me.  i'm happy to provide a ton more information upon request, but am not
sure what you'd want. 

thanks a million, in advance.

-- 
chris mccraw | unix wrangler | university of texas @austin computer sciences