-fabi-version doing nothing?

-fabi-version doing nothing?

[Mike Hearn]

Hi,

I am using this configuration:

[mike@littlegreen frontend-gtk]$ g++ -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linuxThread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

ie a stock FC3 build of g++ 3.4 which defaults to abi version 2.

The following series of commands does not do what I expected:

[mike@littlegreen tmp]$ g++ -o one b.cpp
[mike@littlegreen tmp]$ g++ -fabi-version=1 -o two b.cpp
[mike@littlegreen tmp]$ md5sum one two
093f7ddc1290fa9668fe89c494791aa3  one
093f7ddc1290fa9668fe89c494791aa3  two

ie, the symbol and libstdc++ versions required by the abi-version=1 and 
abi-version=2 binaries are identical. I was sort of expecting 
-fabi-version=1 to make g++ 3.4 produce binaries like version 3.3 
and 3.2 did, ie that depend on libstdc++.so.5 and use GLIBCPP style
symvers not GLIBCXX style.

Am I doing something wrong, am I misunderstanding what this flag is 
supposed to do, or is this a bug in g++?

thanks -mike

Re: -fabi-version doing nothing?

[Nathan Sidwell]

Mike Hearn wrote:

> Am I doing something wrong, am I misunderstanding what this flag is 
> supposed to do, or is this a bug in g++?

the flag controls the layout of classes and vtables, it does not
select a library version.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: -fabi-version doing nothing?

[Mike Hearn]

Nathan Sidwell wrote:
> the flag controls the layout of classes and vtables, it does not
> select a library version.

Perhaps that should be documented. I had always considered the C++ 
standard library to be a part of the C++ ABI.

I was told on IRC that I could get the effect I want by using standard 
gcc as the driver and manually linking in stdc++.so.5 and supc++.a - is 
this a supported general technique (ie will the names/paths of these 
libs change in future)? Is this the right way to convince GCC 3.4 to 
produce C++ binaries that can run on systems with the v1 C++ ABI?

thanks -mike