using older libc for linking process [solved]

[DaggyStyle]

hello.

I have a binary that needed to link against older version of libc, I have all the needed libs in a custom path, how can I force gcc to use that path?
both compiler and lib are 64 bit.

Thanks,

[wcg]

Well, Gentoo has the slot mechanism. I see it in use, but I have not
explored how it works in detail.

There is also LD_LIBRARY_PATH, mainly used for testing according
to the standard documentation on it, but you could wrap your
executable in a script that prepends the path to your other libc
to the standard LD_LIBRARY_PATH:

Code: Select all

#!/bin/sh

LD_LIBRARY_PATH=[custom path to alt libc]:${LD_LIBRARY_PATH}
exec /usr/bin/[name].bin

Rename the executable in /usr/bin (or wherever) to "[name].bin",
and call the script "[name]" (the name of the program that
needs the alternative libc).

Standard documentation:
http://tldp.org/HOWTO/Program-Library-H ... aries.html
(Section 3.3..1)
man ld-linux.so
(The glibc info pages say that executables not running with the uid
of the user executing the command ignore LD_LIBRARY_PATH.)

The linker's -rpath option may solve your problem without LD_LIBRARY_PATH
manipulation. man ld, search for "-rpath".

Finally, you can statically link the binary to your alt libc. (Pass a custom LDFLAGS
to the emerge on the command line.)

[DaggyStyle]

Well, Gentoo has the slot mechanism. I see it in use, but I have not
explored how it works in detail.

There is also LD_LIBRARY_PATH, mainly used for testing according
to the standard documentation on it, but you could wrap your
executable in a script that prepends the path to your other libc
to the standard LD_LIBRARY_PATH:

Code: Select all

#!/bin/sh

LD_LIBRARY_PATH=[custom path to alt libc]:${LD_LIBRARY_PATH}
exec /usr/bin/[name].bin

Rename the executable in /usr/bin (or wherever) to "[name].bin,
and call the script "[name]" (the name of the program that
needs the alternative libc).

Standard documentation:
http://tldp.org/HOWTO/Program-Library-H ... aries.html
(Section 3.3..1)
man ld-linux.so
(The glibc info pages say that executables not running with the uid
of the user executing the command ignore LD_LIBRARY_PATH.)

The linkers -rpath option may solve your problem without LD_LIBRARY_PATH
manipulation. man ld, search for "-rpath".

Finally, you can statically link the binary to your alt libc. (Pass a custom LDFLAGS
to the emerge on the command line.)

statically linking fails when it comes to incompatible glibc implementations.
I don't want to base it on portage as I want to prevent issues when a specific lib get cleared from the tree.
I'll check the other possibilities, thanks.

[Genone]

If gcc is the issue you may have to tell it to ignore the standard libraries and specify your custom libc via -lc and -L/path/to/your/libc.so:

-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
-nodefaultlibs
Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.
-nostdlib
Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker. The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or special needs for some languages.

In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (For example, __main, used to ensure C ++ constructors will be called.)

[DaggyStyle]

If gcc is the issue you may have to tell it to ignore the standard libraries and specify your custom libc via -lc and -L/path/to/your/libc.so:

-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
-nodefaultlibs
Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.
-nostdlib
Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker. The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or special needs for some languages.

In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (For example, __main, used to ensure C ++ constructors will be called.)

that is exactly what I've done but I still don't have full info if it worked from our qa so I still keep the thread unsolved.

[DaggyStyle]

ok, using -nodefaultlibs with -L and -l works well.

[wcg]

Just out of curiousity, how old is this libc that it needs
to link to? What version? What parts of current stable
libc break it?

[DaggyStyle]

Just out of curiousity, how old is this libc that it needs
to link to? What version? What parts of current stable
libc break it?

2.4

if I compile it staticllay it breaks on 2.7 and above.