From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10341 invoked by alias); 20 Jan 2005 00:10:13 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 9377 invoked from network); 20 Jan 2005 00:09:28 -0000 Received: from unknown (HELO mail.cs.utexas.edu) (128.83.139.10) by sourceware.org with SMTP; 20 Jan 2005 00:09:28 -0000 Received: from fidleyhutch.cs.utexas.edu (fool@fidleyhutch.cs.utexas.edu [128.83.144.230]) by mail.cs.utexas.edu (8.13.2/8.13.2) with ESMTP id j0K09SA8029854 for ; Wed, 19 Jan 2005 18:09:28 -0600 (CST) Received: (from fool@localhost) by fidleyhutch.cs.utexas.edu (8.12.11/8.12.11/Submit) id j0K09Sah027470 for binutils@sources.redhat.com; Wed, 19 Jan 2005 18:09:28 -0600 Date: Thu, 20 Jan 2005 00:10:00 -0000 From: Chris McCraw To: binutils@sources.redhat.com Subject: ld's RPATH versus gcc's Message-ID: <20050120000928.GP22279@fidleyhutch.cs.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.6i X-SW-Source: 2005-01/txt/msg00269.txt.bz2 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