Fix gnu versioned namespace mode 00/03

[François Dumont]

On 13/05/2024 10:34, Jonathan Wakely wrote:
>
>
> On Mon, 13 May 2024, 07:30 Iain Sandoe, <idsandoe@googlemail.com> wrote:
>
>
>
>     > On 13 May 2024, at 06:06, François Dumont <frs.dumont@gmail.com>
>     wrote:
>     >
>     >
>     > On 07/05/2024 18:15, Iain Sandoe wrote:
>     >> Hi François
>     >>
>     >>> On 4 May 2024, at 22:11, François Dumont
>     <frs.dumont@gmail.com> wrote:
>     >>>
>     >>> Here is the list of patches to restore gnu versioned namespace
>     mode.
>     >>>
>     >>> 1/3: Bump gnu version namespace
>     >>>
>     >>> This is important to be done first so that once build of gnu
>     versioned namespace is fixed there is no chance to have another
>     build of '__8' version with a different abi than last successful
>     '__8' build.
>
>
>
> The versioned namespace build is not expected to be ABI compatible 
> though, so nobody should be expecting compatibility with previous 
> builds. Especially not on the gcc-15 trunk, a week or two after 
> entering stage 1!

Ok, I really thought that we needed to preserve ABI for a given version, 
'__8' at the moment.


>     >>>
>     >>> 2/3: Fix build using cxx11 abi for versioned namespace
>     >>>
>     >>> 3/3: Proposal to default to "new" abi when dual abi is
>     disabled and accept any default-libstdcxx-abi either dual abi is
>     enabled or not.
>     >>>
>     >>> All testsuite run for following configs:
>     >>>
>     >>> - dual abi
>     >>>
>     >>> - gcc4-compatible only abi
>     >>>
>     >>> - new only abi
>     >>>
>     >>> - versioned namespace abi
>     >> At the risk of delaying this (a bit) - I think we should also
>     consider items like once_call that have broken impls.
>     > Do you have any pointer to this once_call problem, sorry I'm not
>     aware about it (apart from your messages).
>
>     (although this mentions one specific target, it applies more widely).
>
>
> I've removed the "on ppc64le" part from the summary.
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
>
Thanks for the ref, I'll have a look but I fear that I won't be of any 
help here.


>
>     Also, AFAICT, any nested once_call is a problem (not just exceptions).
>
>
> Could you update the bug with that info please?
>
>
>     >>  in the current library - and at least get proposed
>     replacements available behind the versioned namespace; rather than
>     using up a namespace version with the current broken code.
>     >
>     > I'm not proposing to fix all library bugs on all platforms with
>     this patch, just fix the versioned namespace mode.
>
>     Sorry, I was not intending to suggest that (although perhaps my
>     comments read that way).
>
>     I was trying to suggest that, in the case where we have proposed
>     fixes that are blocked because they are ABI breaks, that those
>     could be put behind the versioned namspace (it was not an
>     intention to suggest that such additions should be part of this
>     patch series).
>
>     > As to do so I also need to adopt cxx11 abi in versioned mode it
>     already justify a bump of version.
>
>     I see - it’s just a bit strange that we are bumping a version for
>     a mode that does not currently work; however, i guess someone
>     might have deployed it even so.
>
>
> It does work though, doesn't it?
> It's known to fail on powerpc64 due to conflicts with the ieee128 
> stuff, but it should work elsewhere.
> It doesn't work with --with-default-libstdcxx-abi=cxx11 but that's 
> just a "this doesn't work and isn't supported" limitation.
>
> The point of the patch series is to change it so the versioned 
> namespace always uses the cxx11 ABI, which does seem worth bumping the 
> version (even though the versioned namespace is explicitly not a 
> stable ABI and not backwards compatible).

So I just need to wait for proper review, right ?

This is what I plan to do on this subject for the moment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20240515/4b0ef9c6/attachment.htm>