This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux: Variable dynamic linking


On Monday 04 May 2009 15:21:24 Martin Rosenau wrote:
> I'm not sure if I am correct here so sorry if this email is wrong here.

it's more of a C library question and not specific to the binutils linker

> I'm currently working on a software for Linux that should be distributed
> in binary form because the user should not need to link the software
> himself.
>
> Unfortunately under Linux the dynamic library names are changing (e.g.
> libc.so.5, libc.so.6 / ld-linux.so.1, ld-linux.so.2 / ...).

is supporting that old version of glibc realistic ?  at least glibc-2.2.x used 
libc.so.6 and ld-linux.so.2, and that is almost a decade old.

> So my idea is to write a special statically-linked code that first
> searches the library directories for library files. The file contains
> only the prefixes of the library names (e.g. "ld-linux.so.*" and
> "libc.so.*"). Once the library files and the interpreter (ld.so) has
> been found the code modifies the application (in RAM, not on disk) so
> that the version number is added to the prefixes (libc.so.* =>
> libc.so.6). It maps in ld.so (ld-linux.so.x) and fakes an environment
> that makes ld.so think a dynamically linked application is being loaded.
> Then ld.so is called to do the rest of dynamic loading.
>
> My questions are:
> 1) Will this work? - It makes - of course - only sense if it works under
> different Linux versions.

anything is possible of course, but what you want to do is far from practical 
and most likely will be full of bugs and require a lot of work for little 
return.

problems off the top of my head:
 - you'll have to recreate the initial environment for the loader just like 
the linux kernel does, and do it so that it works on older versions of linux 
as well
 - there is no sane way to handle symbol versioning.  the SONAME isnt changed 
for fun -- it's because there are different symbols (function and data) across 
them.  even linking against a newer version of the SONAME (say glibc-2.9) may 
not result in a working binary with an older SONAME (say glibc-2.6).
 - the loader will perform sanity checks against the ELF it is attempting to 
execute and the libraries available and error out early due to really bad 
problems (like the aforementioned versioning issue).

> 2) Is such a feature or a similar one planned for GNU binutils' "ld"?

no, nor does it really make sense to do so

> 3) Is there another method to distribute binary files that work across
> different Linux versions (linking statically would be one possibility
> but the file sizes are large...)?

the resulting binary will probably be in the megabyte range, but so what ?  
for a binary only app targeting linux desktop systems, that seems fine to me.  
otherwise you can simply release multiple versions of your program linked 
against really old versions of glibc (libc5) and against the oldest libc6 you 
can find.  linking against libc6 from glibc-2.9 is not acceptable.
-mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]