[gcc 4.0.1/Mac OS X 10.4.6 Tiger] multiple vtable definitions for bad_exception and bad_alloc

• Key: STDCXX-262
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Critical
• Assignee: Martin Sebor
• Reporter: Eric Lemings
• Component/s: Build and Installation
• Affects Version/s: 4.1.3
• Fix Version/s: 4.2.0

Description

machine:~/Work user$ svn co http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
A stdcxx/generate.bat
A stdcxx/LICENSE.txt
A stdcxx/tests
A stdcxx/tests/tr1.util
...
A stdcxx/examples/manual/time_put.cpp
A stdcxx/examples/manual/moneyget.cpp
A stdcxx/examples/manual/except.cpp
A stdcxx/examples/manual/memfunc.cpp
Checked out revision 423638.
machine:~/Work user$ cd stdcxx
machine:_{/Work/stdcxx user$ make BUILDDIR="}/Build" BUILDMODE="debug,shared,pthreads"
creating BUILDDIR=/Users/user/Build/stdcxx
generating /Users/user/Build/stdcxx/makefile.in from /Users/user/Work/stdcxx/etc/config/gcc.config
make config

configuring for gcc-4.0.1 on darwin-8.7.1-i386

checking if the compiler is sane ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
checking system architecture ILP32 little endian
...
gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/include -I/Users/user/Build/stdcxx/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC /Users/user/Work/stdcxx/src/wctype.cpp
gcc assert.o atomic-cxx.o bitset.o catalog.o codecvt.o collate.o ctype.o ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o ios_bits.o iostore.o iostream.o iso2022.o limits.o limits_bits.o locale_bits.o locale_body.o locale_classic.o locale_combine.o locale_core.o locale_eq.o locale_global.o locale_name.o memattr.o memory.o messages.o num_get.o num_put.o punct.o random.o setlocale.o string.o strstream.o strtol.o ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o ti_insert_ptr.o ti_ios.o ti_istream.o ti_messages.o ti_money_get.o ti_money_put.o ti_moneypunct.o ti_num_get.o ti_num_put.o ti_numpunct.o ti_ostream.o ti_streambuf.o ti_string.o ti_stringbuf.o ti_time_get.o ti_time_put.o ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o ti_winsert_int.o ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o ti_wmoney_get.o ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o ti_wnumpunct.o ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o ti_wtime_get.o ti_wtime_put.o time_get.o time_put.o tmpbuf.o typeinfo.o valarray.o vecbool.o version.o wcodecvt.o wctype.o -lsupc++ -lgcc_eh -o /Users/user/Build/stdcxx/lib/libstd.dylib.4.2.0
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
exception.o definition of vtable for std::bad_exceptionin section (_DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) private external definition of vtable for std::bad_exceptionin section (_DATA,_const)
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
memory.o definition of vtable for std::bad_allocin section (_DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) private external definition of vtable for std::bad_allocin section (_DATA,_const)
collect2: ld returned 1 exit status
make[2]: *** [/Users/user/Build/stdcxx/lib/libstd.dylib] Error 1
make[1]: *** [lib] Error 2
make: *** [libstd] Error 2

Comments

[Eric Lemings]

This problem is apparently due to a bug in the G++ ABI implementation on Darwin and is supposedly fixed in the GCC 4.2 release series. Hopefully, Apple will pick this regression fix up in a future release. (Leopard/Xcode 3.0 maybe?)

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908 for more details.

[Martin Sebor]

Thanks for the update! From the gcc issue (and the referenced patch) it seems that the problem could be due to the inline definitions of some of the virtual member functions implicitly generated by the compiler. Which makes me wonder if we could fix it by defining the functions explicitly and out of line (as we normally do for the runtime classes).

[Martin Sebor]

I assume the patch fixes the problem. Let me close the issue. Brad, please reopen it if there's still a problem.

[Andrew Black]

I'd need to do a little more digging, but I experienced what appears to be the same problem over the weekend when running a build on my home box. I don't have the logs with me though, so I can't be certain that it's the same issue.

For reference, I'm using a G4 running OS X 10.4.9.

[Andrew Black]

I took some time yesterday to verify that I am still observing this issue with the GCC 4.0.1 compiler using trunk as of yesterday morning, and confirm that I am. This action was prompted in part by a belated revisit of the issue in response to http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[e-mail]%3e

Note that I have changed hardware for my primary development system from the G4 to a Intel Core Duo.

[Martin Sebor]

Sounds like the "fix" is to use a more recent version of gcc. Lowered priority until this is confirmed.

[Martin Sebor]

This is still a problem with the latest trunk and the latest gcc 4.0.1/Xcode 2.0:

gcc -c -I/Users/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -I/Users/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.0.1-11s/include -I/Users/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /Users/sebor/stdcxx/examples/manual/accumulate.cpp
gcc accumulate.o -o accumulate -L/build/sebor/stdcxx-gcc-4.0.1-11s/lib -lstd11s -lsupc++ -lgcc_eh -lm
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
/build/sebor/stdcxx-gcc-4.0.1-11s/lib/libstd11s.a(exception.o) definition of vtable for std::bad_exceptionin section (_DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) private external definition of vtable for std::bad_exceptionin section (_DATA,_const)
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
/build/sebor/stdcxx-gcc-4.0.1-11s/lib/libstd11s.a(memory.o) definition of vtable for std::bad_allocin section (_DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) private external definition of vtable for std::bad_allocin section (_DATA,_const)
collect2: ld returned 1 exit status
make[2]: *** [accumulate] Error 1
make[1]: [examples] Error 2 (ignored)

[Martin Sebor]

Set Priority to Critical (it would be a Blocker if it weren't for the reports that gcc 4.2.0 works).
Set Severity to Linker Error.

[Martin Sebor]

Here's an analysis of what's going on in stdcxx:

1, On Mac OS X, gcc 4.0.1 doesn't generate a vtable for class E in the test case below (which is as expected given that the class dtor isn't defined) but it does so for class D (which is not expected because this dtor also isn't defined), even though there is no "real" difference between the two classes other than the order in which the members are declared.

2. We declare members of std::exception, std::bad_exception, and std::bad_alloc in the same order as those in class D below, i.e., the dtor comes before the other virtual member function. Since we also define some virtual members of these classes (based on the results of config tests which determine that some members are not defined in libsupc+), the vtable for each is generated in the object file where the other members are defined. Since the vtable for all these classes also exists in libsupc+ (that's where the virtual dtor and what() are defined), we end up with two vtables for each class.

3. Given the above, we should be able to work around the problem by reversing the declaration order of the virtual dtor and the other virtual member (what()) so as to trick the compiler into not generating the vtable in our objects.

$ cat t.cpp && uname -srp && gcc -dumpversion && gcc -c t.cpp && nm t.o | c++filt | grep "S vtable"
struct B {
virtual ~B ();
virtual void foo ();
};

struct D: B {
virtual void foo ();
virtual ~D ();
};

struct E: B {
virtual ~E ();
virtual void foo ();
};

void D::foo () { }
void E::foo () { }

Darwin 8.7.1 i386
4.0.1
00000020 S vtable for D

[Martin Sebor]

Attached a patch tested with gcc 4.0.1 on Darwin/x86, gcc 3.4.6 on FreeBSD 6.2/x86, and Intel C++ 9.1 on Red Hat Enterprise Linux AS release 4, Update 2/IA64.

ChangeLog:

2007-09-26 Martin Sebor <[e-mail]>

STDCXX-262

• exception (~exception): Declared after what() to prevent gcc 4
  on Darwin from generating a vtable for the class in exception.o.
  gcc 3.4.6 on FreeBSD 6.2 has no problem either way.
  (~bad_exception): Declared before what() to achieve the same
  effect as above.
• new (~bad_alloc): Declared before what() for the same reason.

[Martin Sebor]

Brad, can you verify that the patch fixes the problem in your environment?

[Eric Lemings]

I just did a build on the latest snapshot of trunk. Looks okay.

[Martin Sebor]

Fix confirmed. Closing.

[Martin Sebor]

Looks like the patch committed at rev 583667 (http://svn.apache.org/viewcvs?view=rev&rev=583667) may be binary incompatible. See: http://www.nabble.com/Re%3A-4.2.0-rc-6%2C-final-candidate-p13227067.html