This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: back at you


In article <16044 dot 15680 dot 23887 dot 296448 at gargle dot gargle dot HOWL>,
Matthias Klose<doko at cs dot tu-berlin dot de> writes:

> please could you give me an advice, how best to test the new
> implementation? I don't have access to an multiprocessor platform.

Well, we really need at least one person with an SMP setup to test it.
It turns out that I have access to such a machine. ;-)

>> (Matthias, this is an ABI change but it is perhaps the correct fix to
>> the problem.  This version as posted will probably silently link
>> against an older libstdc++.so yet fail at runtime.  I think the
>> correct fix is to remove __lock and leave an extern for it; add
>> definition for __lock to a file that only appears in the compiled
>> libstdc++.[a|so].)

> ok, but including this for Debian only would make it incompatible to
> other distros again?

Well, this change will go into gcc 3.3 before it is released thus you
will not be incompatible, right?  Humm, if various Linux distributions
(and this issue also affects FreeBSD/i386 as well) have expected to be
able to compile/link against a libstdc++.so built against i686 but
then run-time link against a libstdc++.so built against i386: That
isn't going to fly given the current architecture of libstdc++-v3.

Do Debian and the other Linux vendors specify the particular canonical
target triple that must be used to ensure ABI portability across
platforms?  I suppose that this was an unexpected/unknown issue to us
when the implementation of atomics for i386-*-* was separated from
i486-*-* (and higher).

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]