|
Home > Archive > Unix Programming > July 2004 > gcc + static linking of libc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gcc + static linking of libc
|
|
| mark greenlancer 2004-07-23, 5:53 pm |
| hello,
I've two systems with different versions of the
glibc (2.3.2 on suse and > 2.5 on debian).
A program which was build on the older version
'won't' run on the system with the newer one
(because the __symb_sigaction is private
declared there).
To run the software on the newer system I will
compile the glibc static (the errmsg on the newer
system said that the symb. can't be found at
link-time reference).
I use a self-made makefile - no configure script.
How to instruct the gcc to do this?
In the manual I've only found '-static' and
'--static-libc'.
I know that the program will grown to a
very big executable file...
greetings,
mark
| |
| Paul Pluzhnikov 2004-07-28, 6:19 pm |
| mark greenlancer <markgreenlancer@aon.at> writes:
> I've two systems with different versions of the
> glibc (2.3.2 on suse and > 2.5 on debian).
Since the current version of glibc (according to
http://www.gnu.org/software/libc/) is 2.3.2, it is quite unlikely
that you have a system with glibc-2.5. Perhaps you meant 2.2.5?
> A program which was build on the older version
> 'won't' run on the system with the newer one
> (because the __symb_sigaction is private
> declared there).
That's very strange: there is no such symbol in any of the glibc's
I have access to. For example, of RedHat Fedora Core2:
$ /lib/libc.so.6 | head -1
GNU C Library stable release version 2.3.3, by Roland McGrath et al.
$ nm /lib/libc.so.6 | grep sigaction
00027e20 t __GI___libc_sigaction
00027f60 t __GI___sigaction
00027e20 T __libc_sigaction
00027f60 W sigaction
00027f60 W __sigaction
> To run the software on the newer system I will
> compile the glibc static (the errmsg on the newer
> system said that the symb. can't be found at
> link-time reference).
Linking against libc statically is a *bad* idea (TM) on any UNIX
system, and is extremely bad idea on Linux. It makes executables
that break in subtle and not-so-subtle ways even with subminor
glibc version differences.
In the thread below, you'll find much info and some solutions:
http://groups.google.com/groups?thr...%40BitWagon.com
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| mark greenlancer 2004-07-28, 6:19 pm |
| Paul Pluzhnikov wrote:
> mark greenlancer <markgreenlancer@aon.at> writes:
>
>
>
>
> Since the current version of glibc (according to
> http://www.gnu.org/software/libc/) is 2.3.2, it is quite unlikely
> that you have a system with glibc-2.5. Perhaps you meant 2.2.5?
>
>
>
>
> That's very strange: there is no such symbol in any of the glibc's
> I have access to. For example, of RedHat Fedora Core2:
>
> $ /lib/libc.so.6 | head -1
> GNU C Library stable release version 2.3.3, by Roland McGrath et al.
> $ nm /lib/libc.so.6 | grep sigaction
> 00027e20 t __GI___libc_sigaction
> 00027f60 t __GI___sigaction
> 00027e20 T __libc_sigaction
> 00027f60 W sigaction
> 00027f60 W __sigaction
Sorry for all the bad information from me, but the last
days I had no access to the specific systems and so I've
wrote it down as far as I can remember it.
I mean the symbol '__libc_sigaction'.
>
>
>
> Linking against libc statically is a *bad* idea (TM) on any UNIX
> system, and is extremely bad idea on Linux. It makes executables
> that break in subtle and not-so-subtle ways even with subminor
> glibc version differences.
>
> In the thread below, you'll find much info and some solutions:
> http://groups.google.com/groups?thr...%40BitWagon.com
>
> Cheers,
Thank you for the info and the work to post it!
greetings,
mark
| |
| Paul Pluzhnikov 2004-07-28, 6:19 pm |
| mark greenlancer <markgreenlancer@aon.at> writes:
> I mean the symbol '__libc_sigaction'.
No object file outside libc itself should be referencing that symbol.
To find out which object in your program is referencing it, re-link
your executable with:
gcc -o a.elf ... -Wl,-y,__libc_sigaction
and fix it to use 'sigaction' instead.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|