--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-12 14:15 ---
(In reply to comment #5)
> on my darwin->i386-unknown-linux-gnu compiler?
It might be because I am using a binutils which has comdat support which is
detected by configure and you did not build a binutils so there i
--- Comment #6 from sabre at nondot dot org 2007-05-12 01:00 ---
The real bug here is that they are not getting internal linkage. Just
uniquing/randifying the names would allow them to link, but could be a perf
issue (more symbols for the static/dynamic linker).
--
http://gcc.gnu.o
--- Comment #5 from mrs at apple dot com 2007-05-12 00:00 ---
Odd, I see:
X:
.long _ZTIN12_GLOBAL__N_13fooE
.weak _ZTSN12_GLOBAL__N_13fooE
.section.gnu.linkonce.r._ZTSN12_GLOBAL__N_13fooE,"a",@progbits
.type _ZTSN12_GLOBAL__N_13fooE, @object
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-11 22:55 ---
(In reply to comment #3)
> I think this is a bug on Linux as well, though, I suspect it don't fail to
> build, but rather I think it will compare the two typeinfo objects as equal
> even though they are unrelated to
--- Comment #3 from mrs at apple dot com 2007-05-11 22:44 ---
I think this is a bug on Linux as well, though, I suspect it don't fail to
build, but rather I think it will compare the two typeinfo objects as equal
even though they are unrelated to each other.
--
mrs at apple dot com c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-11 22:25 ---
debian:~> ~/x86-local-fsf/bin/g++ -c -o t1.o t.cc
debian:~> ~/x86-local-fsf/bin/g++ -c -o t2.o t.cc -DFOO
debian:~> ~/x86-local-fsf/bin/g++ t1.o t2.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-11 22:20 ---
This works correctly on i686-Linux-gnu in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
