public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* ld's RPATH versus gcc's
@ 2005-01-20  0:10 Chris McCraw
  2005-01-20  2:35 ` Ian Lance Taylor
  0 siblings, 1 reply; 6+ messages in thread
From: Chris McCraw @ 2005-01-20  0:10 UTC (permalink / raw)
  To: binutils


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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-21  0:47 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-20  0:10 ld's RPATH versus gcc's Chris McCraw
2005-01-20  2:35 ` Ian Lance Taylor
2005-01-20 21:43   ` Chris McCraw
2005-01-20 23:47     ` Andreas Schwab
2005-01-20 23:54       ` Chris McCraw
2005-01-21  0:47         ` Andreas Schwab

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).