Discussion:
BUG -- Apps made on FC5 (GCC 4.1.1) do NOT run on FC3 (GCC 4.0.2)
(too old to reply)
Ignoramus20785
2007-01-31 14:51:09 UTC
Permalink
We have an app that we compile on FC5 (Fedora Core 5) using g++ from
GCC 4.1.1.

When we copy our app to a FC3 server, to run it, we get this error:

our_program: /lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by our_program)

Further investigation was done with command

$ objdump -T our_program|grep GCC_4
00000000 DF *UND* 00000019 GCC_4.2.0 _Unwind_GetIPInfo

That means that of this big program, only one function
_Unwind_GetIPInfo requires symbol GCC_4.2.0 to be defined. All others
need GCC_3.*.

That symbol is mentioned in /usr/lib/libstdc++.so.6 and /lib/libgcc_s.so.1.
My guess (which may be wrong) is that libgcc_s defines it and libstdc++ requires it.

My main question is WTF?? Why would only one symbol require a new library?

What can I do to get C++ apps compiled on FC5 to run on FC3?

I am very desperate for help. Thanks a lot.

i
Paul Pluzhnikov
2007-01-31 15:26:27 UTC
Permalink
Post by Ignoramus20785
We have an app that we compile on FC5 (Fedora Core 5) using g++ from
GCC 4.1.1.
This is expected.

Unlike Win32, UNIX systems generally support *only* backward
compatibility: programs compiled on an older system continue to run
on a newer one (i.e. compile on FC3, run on FC5, and it will work).
Post by Ignoramus20785
What can I do to get C++ apps compiled on FC5 to run on FC3?
The answer is: compile on the lowest OS release instead.

If there is a good reason why you can't, then you have to get rid
of libstdc++.so.6 and libgcc_s.so.1 dependency [1], or you have to
arrange for FC5 libraries to be used on the FC3 system [2].

For [1], do this:

ln -sf $(g++ --print-file-name=libstdc++.a) .
g++ -static-libgcc -o exe main.o ... -L.
rm libstdc++.a

# exe now has libgcc.a and libstdc++.a statically linked in.

For [2], do this:

g++ -o exe main.o ... -Wl,-rpath='$ORIGIN'

Now copy 'exe' and libgcc_s.so.1 and libstdc++.so.6 into the same
directory on FC3.

Note that either solution may work, but is not at all guaranteed
to work.

Also, a slight modification to source may break it again -- there
are symbols in FC5 libc, which are not present in FC3 libc, and if
you introduce any code that depends on these, you are screwed.


Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Ignoramus20785
2007-01-31 15:46:37 UTC
Permalink
Paul, thanks a lot, I will try approach [1] first. It will take ma few
hours as I need to recompile a lot of stuff on a busy obsolete
computer. I will post an update. Thank you.,

i
Post by Paul Pluzhnikov
Post by Ignoramus20785
We have an app that we compile on FC5 (Fedora Core 5) using g++ from
GCC 4.1.1.
This is expected.
Unlike Win32, UNIX systems generally support *only* backward
compatibility: programs compiled on an older system continue to run
on a newer one (i.e. compile on FC3, run on FC5, and it will work).
Post by Ignoramus20785
What can I do to get C++ apps compiled on FC5 to run on FC3?
The answer is: compile on the lowest OS release instead.
If there is a good reason why you can't, then you have to get rid
of libstdc++.so.6 and libgcc_s.so.1 dependency [1], or you have to
arrange for FC5 libraries to be used on the FC3 system [2].
ln -sf $(g++ --print-file-name=libstdc++.a) .
g++ -static-libgcc -o exe main.o ... -L.
rm libstdc++.a
# exe now has libgcc.a and libstdc++.a statically linked in.
g++ -o exe main.o ... -Wl,-rpath='$ORIGIN'
Now copy 'exe' and libgcc_s.so.1 and libstdc++.so.6 into the same
directory on FC3.
Note that either solution may work, but is not at all guaranteed
to work.
Also, a slight modification to source may break it again -- there
are symbols in FC5 libc, which are not present in FC3 libc, and if
you introduce any code that depends on these, you are screwed.
Ignoramus20785
2007-01-31 19:48:24 UTC
Permalink
Paul,

I tried your suggestion. It did remove dependency on libstdc++. Which
is great. Thank you.

However, it looks like we have one more issue: all of our shared
libraries that we build from our code (that come with the executable
in question) have references to function _Unwind_GetIPInfo. That
function, in turn, requires GCC_4.2.0.

See below.

Is there something that we can do to not call that _Unwind_GetIPInfo?

Thanks!!!

00000000 F *UND* 0000000b _Unwind_GetTextRelBase@@GCC_3.0
00000000 F *UND* 00000019 _Unwind_GetIPInfo@@GCC_4.2.0
00000000 F *UND* 00000063 _Unwind_SetGR@@GCC_3.0
00000000 F *UND* 000000f9 _Unwind_Resume_or_Rethrow@@GCC_3.3
00000000 F *UND* 0000000b _Unwind_GetLanguageSpecificData@@GCC_3.0
00000000 F *UND* 0000000b _Unwind_GetRegionStart@@GCC_3.0
00000000 F *UND* 0000000e _Unwind_SetIP@@GCC_3.0
00000000 F *UND* 00000197 _Unwind_RaiseException@@GCC_3.0
00000000 F *UND* 0000000b _Unwind_GetDataRelBase@@GCC_3.0
00000000 F *UND* 0000001f _Unwind_DeleteException@@GCC_3.0
00000000 F *UND* 000000e9 _Unwind_Resume@@GCC_3.0
00000000 DF *UND* 0000000b GCC_3.0 _Unwind_GetTextRelBase
00000000 DF *UND* 00000019 GCC_4.2.0 _Unwind_GetIPInfo
00000000 DF *UND* 00000063 GCC_3.0 _Unwind_SetGR
00000000 DF *UND* 000000f9 GCC_3.3 _Unwind_Resume_or_Rethrow
00000000 DF *UND* 0000000b GCC_3.0 _Unwind_GetLanguageSpecificData
00000000 DF *UND* 0000000b GCC_3.0 _Unwind_GetRegionStart
00000000 DF *UND* 0000000e GCC_3.0 _Unwind_SetIP
00000000 DF *UND* 00000197 GCC_3.0 _Unwind_RaiseException
00000000 DF *UND* 0000000b GCC_3.0 _Unwind_GetDataRelBase
00000000 DF *UND* 0000001f GCC_3.0 _Unwind_DeleteException
00000000 DF *UND* 000000e9 GCC_3.0 _Unwind_Resume
Post by Paul Pluzhnikov
Post by Ignoramus20785
We have an app that we compile on FC5 (Fedora Core 5) using g++ from
GCC 4.1.1.
This is expected.
Unlike Win32, UNIX systems generally support *only* backward
compatibility: programs compiled on an older system continue to run
on a newer one (i.e. compile on FC3, run on FC5, and it will work).
Post by Ignoramus20785
What can I do to get C++ apps compiled on FC5 to run on FC3?
The answer is: compile on the lowest OS release instead.
If there is a good reason why you can't, then you have to get rid
of libstdc++.so.6 and libgcc_s.so.1 dependency [1], or you have to
arrange for FC5 libraries to be used on the FC3 system [2].
ln -sf $(g++ --print-file-name=libstdc++.a) .
g++ -static-libgcc -o exe main.o ... -L.
rm libstdc++.a
# exe now has libgcc.a and libstdc++.a statically linked in.
g++ -o exe main.o ... -Wl,-rpath='$ORIGIN'
Now copy 'exe' and libgcc_s.so.1 and libstdc++.so.6 into the same
directory on FC3.
Note that either solution may work, but is not at all guaranteed
to work.
Also, a slight modification to source may break it again -- there
are symbols in FC5 libc, which are not present in FC3 libc, and if
you introduce any code that depends on these, you are screwed.
Paul Pluzhnikov
2007-02-01 04:38:54 UTC
Permalink
Post by Ignoramus20785
I tried your suggestion. It did remove dependency on libstdc++. Which
is great. Thank you.
However, it looks like we have one more issue: all of our shared
libraries that we build from our code (that come with the executable
in question) have references to function _Unwind_GetIPInfo. That
function, in turn, requires GCC_4.2.0.
You never mentioned shared libraries before. They present a whole
another set of complications.
Post by Ignoramus20785
Is there something that we can do to not call that _Unwind_GetIPInfo?
I can't find any way of getting my objects reference that function.
Did you by any chance do this:

ln -sf $(g++ --print-file-name=libstdc++.a) .
g++ foo.o bar.o -o foo.so -shared -static-libgcc -L.

[That's the only way I figured out to get a shared library that
requires _Unwind_GetIPInfo.]

Don't do *that*; link them "normally" instead:

g++ foo.o bar.o -o foo.so -shared
Please do not top-post.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Loading...