[Mozart with] gcc3, ABI, binary tar"balls, build from sources
Konstantin Popov
kost at sics.se
Fri Feb 27 12:36:05 CET 2004
Dear all,
in the course of the release work, I (both fortunately and
unfortunately;-) encountered (and got stuck for a while ;-) the issue
of ABI incompatibility between new (gcc 3.2 onwards) and old (notably
gcc 2.95.3). A quick web scan suggested that it was the C++ interface,
but people generally say "don't mix binaries and libraries from
different gcc"s".
This is an issue for both the linux binary tar"balls and building from
sources. One can build a usable set for "newer" Linux distributions -
those that are built with gcc3.2+, in particular concerning the system
libraries, binutils and probably the dynamic linker as well. Building
Mozart on "older" systems can yield unusable results. Specifically, I
tried to use the gcc3.3.2 with -O3 on my RedHat7.3 (regularly
maintained, though) box, and got a '.so' library (DPB.so) that cannot
properly access its own variables with global (i.e. file) scope. More
technically, the code that calculates the actual location of such a
variable using the "global offset table" produces wrong address.
Statically linked emulator.exe works fine. Doing less optimizations
(e.g. -O2) SOMEHOW (I did not study this issue) resolved the trouble
as well.
The following observation confirmed my theory that it is the ABI
issue, specifically - the incompatibility between gcc and gas (a part
of binutils). In the non-working environment (RedHat7.3 + gcc3.3.2) I
produced the assembly file for the C++ code (libdp/tcpConnection.cc)
that caused the trouble. I then successfully assembled that '.s' file
and built a working '.so' (DPB.so) library using it in the working
environment (RedHat9.0 + gcc 3.3.2), while transferring the
corresponding '.lo' file and using it for building '.so' library
yielded a non-working library.
The binary tar"balls will be produced, as they were before, in the
environment that contains a specific version of binutils
(binutils-2.13 is claimed to understand both new and old ABI"s?), so
I'll report whether binaries produced this way will be usable on
"older" linux distributions.
Unfortunately, I have NO idea what implication that is going to have
on other platforms. The C++ ABI implemented with gcc3.2+ is claimed to
be "implemented by other compiler vendors", so building Mozart should
only get better. I gonna try Solaris, but have to rely on you, guys,
elsewhere. Comments? Suggestions? Thoughts?
Cheers,
--- Kostja.
More information about the mozart-hackers
mailing list