PATCH: back at you

[Loren James Rittle]

In article <16044.15680.23887.296448@gargle.gargle.HOWL>,
Matthias Klose<doko@cs.tu-berlin.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