Re: How to make an application look somewhere other than /lib for ld-linux.so.2

["Mark Cuss" <mcuss@cdlsystems.com>]

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" <karuottu@mbnet.fi>
To: "Mark Cuss" <mcuss@cdlsystems.com>
Cc: <gcc@gcc.gnu.org>
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
> <snip>
>   -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...
>
>
>