--- Comment #13 from davek at gcc dot gnu dot org 2009-12-20 19:59 ---
(In reply to comment #12)
(In reply to comment #11)
(In reply to comment #10)
Should be fixed in SVN now. Rainer, please verify when you get a chance.
Seems to work now!
Rainer
That counts as
--- Comment #11 from rainer at emrich-ebersheim dot de 2009-12-18 10:02
---
(In reply to comment #10)
Should be fixed in SVN now. Rainer, please verify when you get a chance.
Today I will try to build a complete tool chain with shared libstdc++ enabled.
I will report back.
--
--- Comment #12 from rainer at emrich-ebersheim dot de 2009-12-18 15:29
---
(In reply to comment #11)
(In reply to comment #10)
Should be fixed in SVN now. Rainer, please verify when you get a chance.
Today I will try to build a complete tool chain with shared libstdc++
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-17 09:04 ---
This is starting to look like an LD bug. The function is there in the objects
fed into the final link:
$ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve
t .text$_ZNSs7reserveEy
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 10:07 ---
Ok, it's not an LD bug. LD is doing the right thing, which in this case turns
out to be filtering it out of the list of exports due to the version script.
In the 32-bit multilib, we have this version of
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-17 10:20 ---
Starting to think that actually this is just how the ABI should be for w64 and
the version script for libstdc++ just has a weakness. If I'm guessing right,
it's because w64 is the only LLP64 target that is why this
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 10:25
---
Under linux, it's just unsigned long, which is 64-bit anyway, because actually
it's a size_t. Seems strange that we didn't notice yet, but it's well possible
that on some 64-bit systems a size_t is an unsigned
--- Comment #7 from davek at gcc dot gnu dot org 2009-12-17 11:27 ---
Created an attachment (id=19336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19336action=view)
differences between 32-bit and 64-bit exported symbols
There's a bunch more missing than just
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-17 11:52 ---
Created an attachment (id=19338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19338action=view)
salient diffs extracted
I removed all the matching +/- line pairs from the raw diff file where a
signature changed
--- Comment #9 from davek at gcc dot gnu dot org 2009-12-17 15:25 ---
Subject: Bug 42377
Author: davek
Date: Thu Dec 17 15:25:36 2009
New Revision: 155318
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155318
Log:
PR target/42377
* config/abi/pre/gnu.ver: Adjust
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-17 15:27 ---
Should be fixed in SVN now. Rainer, please verify when you get a chance.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davek at gcc dot gnu dot org 2009-12-15 11:49 ---
Hi Rainer, it'll take a little time but I'll set myself up a build environment
and see if I can reproduce this.
The libtool dependency libs stuff is a known problem in libtool IIRC. Details
to follow.
--
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-12-15 14:25
---
(In reply to comment #1)
Hi Rainer, it'll take a little time but I'll set myself up a build
environment
and see if I can reproduce this.
The libtool dependency libs stuff is a known problem in libtool
13 matches
Mail list logo
