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

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

[Daniel Kegel]

"Mark Cuss" <mcuss@cdlsystems.com> wrote:
> 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.
 > I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc.
> ...
> 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.

There are two official ways to go:

1) Build static binaries.  (If your apps use libnss*.a, you may want to
    configure your toolchain's glibc with --enable-static-nss; I'm
    doing that now for one project.  Don't tell drepper.)
2) Build your apps with lsbcc.  That will link to the LSB's
    frozen version of libstdc++, etc.

#1 is doable right now.  #2 is, too, but requires your users to
install your distro's LSB runtime package.

- Dan

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

[Mark Cuss]

Ok - thanks.

For #1, if I build with --static, then no libraries can be linked in 
dynamically at runtime...  I need to do this for some custom Qt libraries 
and plugins, so I can't just make a completely static executable.  This is 
unfortunate - the resulting binaries would be big, but they'd work on any 
distro.

#2 - I'd never heard of LSB or lsbcc...  I've just done a google and turned 
up an article on an IBM website on building binary-compatible Linux 
applications...  Thanks for the pointer on this one - it looks like this may 
be the way to go.

Mark

----- Original Message ----- 
From: "Daniel Kegel" <dank@kegel.com>
To: <gcc@gcc.gnu.org>; "Mark Cuss" <mcuss@cdlsystems.com>
Sent: Thursday, July 14, 2005 4:07 PM
Subject: How to make an application look somewhere other than /lib for 
ld-linux.so.2


> "Mark Cuss" <mcuss@cdlsystems.com> wrote:
>> 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.
> > I run into problems all the time when different distros have different 
> > versions of system libraries like libstdc++, libgcc, libc, etc.
>> ...
>> 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.
>
> There are two official ways to go:
>
> 1) Build static binaries.  (If your apps use libnss*.a, you may want to
>    configure your toolchain's glibc with --enable-static-nss; I'm
>    doing that now for one project.  Don't tell drepper.)
> 2) Build your apps with lsbcc.  That will link to the LSB's
>    frozen version of libstdc++, etc.
>
> #1 is doable right now.  #2 is, too, but requires your users to
> install your distro's LSB runtime package.
>
> - Dan
>
> 

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

[Haren Visavadia]

--- Mark Cuss wrote:
> 
> For #1, if I build with --static, then no libraries
> can be linked in 
> dynamically at runtime...  I need to do this for
> some custom Qt libraries 
> and plugins, so I can't just make a completely
> static executable.  This is 
> unfortunate - the resulting binaries would be big,
> but they'd work on any 
> distro.

This is possible by using something like
-Wl,-Bdynamic, (insert list of libraries to be
dynamically linked),-Bstatic

For example, if you want to dynamically link against
Qt library and glibc and rest of it being static, you
can use -Wl,-Bdynamic,-lqt-mt,-lc,-Bstatic









	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

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

[Mark Cuss]

Oh!  I didn't know you could do that!  Thanks very much!

Mark

----- Original Message ----- 
From: "Haren Visavadia" <themis_hv@yahoo.co.uk>
To: "Mark Cuss" <mcuss@cdlsystems.com>
Cc: <gcc@gcc.gnu.org>
Sent: Tuesday, July 26, 2005 1:29 PM
Subject: Re: How to make an application look somewhere other than /lib for 
ld-linux.so.2


> --- Mark Cuss wrote:
>>
>> For #1, if I build with --static, then no libraries
>> can be linked in
>> dynamically at runtime...  I need to do this for
>> some custom Qt libraries
>> and plugins, so I can't just make a completely
>> static executable.  This is
>> unfortunate - the resulting binaries would be big,
>> but they'd work on any
>> distro.
>
> This is possible by using something like
> -Wl,-Bdynamic, (insert list of libraries to be
> dynamically linked),-Bstatic
>
> For example, if you want to dynamically link against
> Qt library and glibc and rest of it being static, you
> can use -Wl,-Bdynamic,-lqt-mt,-lc,-Bstatic
>
>
>
>
>
>
>
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with 
> voicemail http://uk.messenger.yahoo.com
> 

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

[Bob Proulx]

Mark Cuss wrote:
> 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.

Why restrict yourself to a small subset of the list of distros?  With
a little bit of effort you can handle Debian, Ubuntu, SuSE, Mandrake
and others too.

This question was asked a while go on another mailing list.  I posted
what I do there in that list.  Here is a pointer to an archive of my
method of platform independence.  Basically I bundle all of the
libraries and wrap the executable in a script wrapper.

  http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=32310

This is off-topic for this list.  But I am happy to discuss the issues
with you either directly or in a more appropriate forum.

Bob

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

[Ranjit Mathew]

Mark Cuss wrote:
> 
> 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.

Perhaps you can just ship a bunch of object files and do the
final linking only as a part of your installation process. Of course,
since the C++ ABI changed with GCC 3.x, you might want to bundle
the C++ libraries, but leave out everything else. It would also
mean that end-users have to have binutils, and perhaps make, installed
on their machines as a pre-requisite.

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/

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

[Mark Cuss]

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...
>
>
> 

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

[Kai Ruottu]

Kai Ruottu kirjoitti:
> Mark Cuss kirjoitti:
>> 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.

  Seems that also I must learn to read much better!!! Not thinking that
"others cannot ever even read". Not very good results yet got...  My
apologies for not reading what Mark wrote!!!

  So '-rpath' was tried but not yet the '-dynamic-linker', which must
be used for the 'ld-linux.so.2', 'ld.so.1' or something depending on
the Linux, SVR4 etc. variation...

  Finding the "dynamic linker", "program interpreter" or whatever the
official name then is, from the right place at runtime can be a problem,
but it is also a problem at linktime!!!  Here is my clue for those who
yet don't know how on earth the search place for those "NEEDED" shared
libraries (told inside other shared libraries being needed too when
linking) :

---------------------- clip ----------------------
F:\usr\local\i486-linux-gnu\bin>ld -verbose

GNU ld version 2.10.1 (with BFD 2.10.1)
   Supported emulations:
    elf_i386
    i386linux
using internal linker script:
==================================================
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
               "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
  SEARCH_DIR(/usr/local/i486-linux-gnu/lib);
/* Do we need any of these for elf?
    __DYNAMIC = 0;    */
SECTIONS
---------------------- clip ----------------------

  The "SEARCH_DIR" told in the internal linker script seems to be the
place where the stuff will be searched...

  Sometimes there was a bug in this and using '-rpath-link' was
obligatory.  Nowadays there can be a problem with the bi-arch
(64/32-bit) targets like 'x86_64-linux-gnu', using '-m elf_i386'
in the linker command gives something like :

---------------------- clip ----------------------
GNU ld version 020322 20020322
   Supported emulations:
    elf_x86_64
    elf_i386
    i386linux
using internal linker script:
==================================================
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
               "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
  SEARCH_DIR("/usr/local/i386-linux-gnu/lib");
---------------------- clip ----------------------

  So the linker was made for 'x86_64-linux-gnu' but it searches from
'.../i386-linux-gnu/lib' for the 32-bit 'ld-linux.so.2' at linktime.
Who could have guessed this?

  I haven't though checked how the uptodate linkers behave...

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

[Kai Ruottu]

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...

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

[Mark Cuss]

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:

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.  I run into problems all the time 
when different distros have different versions of system libraries like 
libstdc++, libgcc, libc, etc.

So, I built myself a new gcc-3.4.4 compiler and build a simple "hello world" 
program with it on a RH8 machine.  An ldd on this program yields
[mark@locutus helloworld]$ ldd a.out
        libstdc++.so.6 => 
/cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libstdc++.so.6 (0x40015000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40102000)
        libgcc_s.so.1 => 
/cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libgcc_s.so.1 (0x40124000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[mark@locutus helloworld]$

Note that ldd is using the libstdc++ library that got built when the 
compiler was built - this seems like a good thing to me.

To make this application run on a Red Hat 7.3 machine, I grabbed the system 
libraries that a.out depends upon (libc, libm) and copied them into my 
application's directory and changed LD_LIBRARY_PATH to point there.  Now ldd 
outputs:
[mark@locutus helloworld]$ ldd a.out
        libstdc++.so.6 => 
/cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libstdc++.so.6 (0x40015000)
        libm.so.6 => ./libm.so.6 (0x400ee000)
        libgcc_s.so.1 => 
/cdl/apps/.software/linux/gcc-3.4.4-x86-x86/lib/libgcc_s.so.1 (0x40110000)
        libc.so.6 => ./libc.so.6 (0x40119000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[mark@locutus helloworld]$

Note that ldd now picks up my local copies of libc and libm, but not of 
ld-linux.  This program runs like this OK on Red Hat 7.3 when built on a RH8 
machine, but not on an RHEL linux machine because the run-time linker is 
trying to use /lib/ld-linux.so.2 with my local copy of libc.so.6.  The exact 
error message is:
[mark@hugh helloworld]$ ./a.out
./a.out: relocation error: ./libc.so.6: symbol _dl_starting_up, version 
GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
[mark@hugh helloworld]$

This makes sense to me - the version of ld-linux.so and libc must match.

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.

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.

Thanks
Mark


Mark Cuss, B. Sc.
Real Time Systems Analyst
System Administrator
CDL Systems Ltd
Suite 230
3553 - 31 Street NW
Calgary, AB, Canada

Phone: 403 289 1733 ext 226
Fax: 403 289 3967
www.cdlsystems.com