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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]