From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28689 invoked by alias); 26 Jul 2005 19:17:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28659 invoked by uid 22791); 26 Jul 2005 19:17:44 -0000 Received: from [207.34.103.174] (HELO cdlsystems.com) (207.34.103.174) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Tue, 26 Jul 2005 19:17:44 +0000 Received: from pinchy by cdlsystems.com (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000248326.msg for ; Tue, 26 Jul 2005 13:17:38 -0600 Message-ID: <01b201c59216$ab99db10$ab0e10ac@pinchy> Reply-To: "Mark Cuss" From: "Mark Cuss" To: Cc: References: <00b401c588be$477aa170$ab0e10ac@pinchy> <42D78F98.9040801@mbnet.fi> Subject: Re: How to make an application look somewhere other than /lib for ld-linux.so.2 Date: Tue, 26 Jul 2005 19:17:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Authenticated-Sender: mark@cdlsystems.com X-Spam-Processed: cdlsystems.com, Tue, 26 Jul 2005 13:17:38 -0600 (not processed: message from valid local sender) X-Return-Path: mcuss@cdlsystems.com X-MDaemon-Deliver-To: gcc@gcc.gnu.org X-MDAV-Processed: cdlsystems.com, Tue, 26 Jul 2005 13:17:42 -0600 X-SW-Source: 2005-07/txt/msg01102.txt.bz2 I appreciate your help, but I don't really appreciate the way you insinuate that I didn't do some leg work before running off to the mailing list. I *DID* RTFM, thank you very much. I found the -rpath option, tried it, and it didn't work. I mentioned this in my original post - I was confused as to why the option didn't do what it was supposed to do, so I posed the question here as I figured the experts here would now why the option didn't work and would perhaps provide a solution. I'm pretty certain that I'm not the only person who struggles with the "Oh, that app was built on RH 8 so it won't run on RH 7.3" problems, so I'm trying to find a solution where I can configure my build system in such a way that I can distribute a set of libraries with my applications to that it will run on any distro - at least all of the Red Hats, Fedora Cores, and RHELs anyways. Mark ----- Original Message ----- From: "Kai Ruottu" To: "Mark Cuss" Cc: Sent: Friday, July 15, 2005 4:27 AM Subject: Re: How to make an application look somewhere other than /lib for ld-linux.so.2 > Mark Cuss kirjoitti: >> Hello all >> >> I apologize if this is off topic for this list - I wasn't sure exactly >> where to ask but I thought this would be a good place to start: > > Something for newbies like gcc-help? > >> I'm trying to get myself a group of libraries that I can distribute with >> my program so that they'll run on any distro. > > On SuSEs, Mandrakes, Debians,...? Or on only Red Hats and Fedoras? > >> I run into problems all the time when different distros have different >> versions of system libraries like libstdc++, libgcc, libc, etc. > > Excluding libstdc++*.so's all these should be backwards compatible > with old apps produced on old systems... But usually only among the > same "company". So Red Hat 8.0 should run apps made for Red Hat 6.x > and 7.x and maybe even older apps made for "Red Hat". This is what > one could expect, an opsys made for company use must be "stable" in > the sense that in some time frame all apps made for it should run... > > In the (bad?) Windoze, SCO, UnixWare, Solaris2 etc. worlds this > backwards-compatability issue has always taken seriously. But I > remember in 1994 the (Finnish) Linux experts to tell that Linux > WILL NEVER have any "backwards compatability" or any binary > compatability between its distros! People are assumed to rebuild > all apps to the new Linux installations! People like me who thought > things like the then new Novell UnixWare to be "a good thing" because > it claimed compatability with almost every source and binary made > that far, were doomed as being "heretics"... > > But Linux entering into the company world has caused pressure for > "binary compatability" a'la MS, SCO,... So nowadays one can download > a new "Firefox 1.0.5" for Linux/x86 and expect it to work OK on one's > Red Hat, SuSE, Debian and so on !!! That this is possible, must be a > horrible disappointment to the old Linux users... > >> To make this application run on a Red Hat 7.3 machine, > > At least the backwards compatability for apps made for Red Hat 7.3 > has this far seemed perfect... Alls the apps made for RHL 7.3 on RH 8.0 > by me have run OK both on RH 8.0 and on RH 7.x too... > > So my advice is to produce the apps for the "least common nominator". > Maybe Red Hat 7.3 could be this for RH 7.x, 8.0 and 9, and for the > Fedora Cores. But I have no experience about the SuSEs. Maybe one > must have a similar "least common nominator" toolchain for those... > >> So - the question is: How do I do this? Even though LD_LIBRARY_PATH >> points to ./ as it's first entry, ldd still looks in /lib first for >> ld-linux.so.2. I've tried the rpath option to ld at link time, but that >> doesn't work either. It seems that thing is somehow hardcoded to look in >> /lib for this library. > > Trying the backwards compatability sounds being the natural thing > for me. Generally those "native GCCs" used as the production tools > for any apps (excluding the GCCs) is from the ass, IMHO... Instead > one should produce "portable GCCs" so that when one has produced > several GCCs for the then installed host, one could just copy them > to the (backwards compatible) new Linux distro. Without rebuilding > them. Heretics maybe, but struggling with trying to produce egcs-1.1.2 > for RHL 6.2 target using gcc-3.4 or something on Fedora is really > not seen as any alternative by me if needing to produce apps for RH 6.2 > on Fedora... Sometimes in the past I understood that "native GCCs are > from the ass" and after that I have produced only crosscompilers for > everything, even for the "native" target... On my RHL 8.0 all the GCCs > for RHL 8.0 target are crosscompilers for RHL 8.0. And made for the > current "least common nominator" runtime host, RHL 7.3... > >> Is there a way to somehow configure gcc build executables that look >> elsewhere for ld-linux.so.2, or is what I'm trying to do simply not >> possible? I'd really like to have a set of libraries with my program so >> that it's binary compatible with other distros... there must be a way. >> If anyone has any tips or advice I'd appreciate it. > > What about learning the "--help" option? When you link, you can force > the resulted apps to search their shared libraries from anywhere : > > F:\usr\local\i486-linux-gnu\bin>ld --help > Usage: ld [options] file... > Options: > -a KEYWORD Shared library control for HP/UX > compatibility > -A ARCH, --architecture ARCH > Set architecture > -b TARGET, --format TARGET Specify target for following input files > > -rpath PATH Set runtime shared library search path > -rpath-link PATH Set link time shared library search path > > Finding the option for "Set runtime shared library search path" needs > only newbie level skills, ie capability to write "--help" and read :-) > RTFM then tells more, again capability to read is required... Producing > nice manuals for the GNU tools from their texinfo sources is also quite > newbie level skill. Some can even use MS Word or the text processor in > OpenOffice and invent their own clauses, only converting existing things > to some other format should be 10 times easier... > > >