Re: LO 24.2 C++20 baseline

[Terrence Enger]

On Tue, 2023-09-26 at 10:44 +0200, Miklos Vajna wrote:
> Hi,
> 
> On Mon, Sep 25, 2023 at 01:48:01PM +0300, Stephan Bergmann 
>  wrote:
> > Was that maybe an intermittent Clang bug?  It apparently doesn't hit the
> > Jenkins Clang builds, and I don't see it with trunk Clang 18 either, but
> > have dim memories that there was some issue with too-eager evaluation
> > causing something like this at some point.  Do you have a way to check with
> > another Clang version, to substantiate that assumption?
> 
> Yes, I can confirm downgrading to clang-12 would work around the
> problem.
> 

The phrase "too-eager evaluation" caught my eye here.  What I see may
be something else entirely, but here goes.  I hesitate to bring it up,
because I am getting along just fine without building skia, but maybe
this will save someone a few minutes of investigation.

I am running debian-sid with clang-14 and libstdc++-13-dev.  With
-std=c++20, clang++ complains about /usr/include/c++/13/chrono:

/usr/include/c++/13/chrono:2320:48: error: call to consteval function
'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
  ^
/usr/include/c++/13/chrono:2320:48: note: undefined function 
'_S_fractional_width' cannot be
used in a constant expression
/usr/include/c++/13/chrono:2275:2: note: declared here
_S_fractional_width()

I see the problem only with C++20 and that version of the compiler and
libstdc++.  I see no error message with

- gcc version 13.2.0-7

- libstdc++ version 12: both _S_fractional_width and
  fractional_width are constexpr

- default version of C++

I shall copy in an excerpt from typescript of the failing build of LO
at the end of this message.

Terry.

excerpt from typescript of build

[CXX]
workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:8:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.h:19:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/core/SkImageFilterTypes.h:20:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/core/SkSpecialImage.h:19:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/gpu/ganesh/GrSurfaceProxyView.h:1
8:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/gpu/ganesh/GrSurfaceProxy.h:22:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/gpu/ganesh/GrGpuResource.h:14:
In file included from
/home/terry/lo_hacking/git/libo6/workdir/UnpackedTarball/skia/src/gpu/GpuTypesPriv.h:13:
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48:
 error: call to
consteval function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a 
constant expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48:
 note: undefined
function '_S_fractional_width' cannot be used in a constant expression
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2275:2:
 note: declared
here
_S_fractional_width()
^

Re: LO 24.2 C++20 baseline

[Heiko Tietze]

On 05.10.23 16:49, Stephan Bergmann wrote:
As we just found out on IRC when Heiko ran into the above failures when 
compiling cli_ure/source/climaker/climaker_app.cxx, this apparently also affects 
old versions of VS 2022, not just VS 2019:
No issue building master with VS Build Tools 17.7.4 which updated MSVC22 to 
14.36.32532 yesterday.


--
Dr. Heiko Tietze, UX-Designer and UX-Mentor
Tel: +49 30 5557992-63 | Mail: heiko.tie...@documentfoundation.org
The Document Foundation, Winterfeldtstraße 52, 10781 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: LO 24.2 C++20 baseline

[Stephan Bergmann]

On 10/4/23 13:56, Stephan Bergmann wrote:
As 
 "Drop some newly obsolete __cplusplus version checks" revealed, "at least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in /clr mode (e.g., when compiling cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively ignored, and compilation of such source files failed with


include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use 
of class template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 
'rtl::OStringLiteral'
include\rtl/string.hxx(191): error C7592: a non-type 
template-parameter of type 'rtl::OStringLiteral' requires at least 
'/std:c++20'
include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use 
of class template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 
'rtl::OStringLiteral'


etc.  To work around that, keep the 
 'O[U]String literals (unusable for now, C++20 only)' functionality disabled when compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler."


As we just found out on IRC when Heiko ran into the above failures when 
compiling cli_ure/source/climaker/climaker_app.cxx, this apparently also 
affects old versions of VS 2022, not just VS 2019:



Okt 05 14:58:32htietze, (1) what exact version of MSVC are you 
using?  (2) show a useful tail of your log, not just a single line
Okt 05 15:01:50  10.0.40219 MSVC++ 2010 (according the apps info)
Okt 05 15:02:11  and 14.30.30704 2015-2022
Okt 05 15:03:12  VS Build Tools 2022 / 17.7.4
Okt 05 15:04:50htietze, according to 
, "14.30" probably 
means "Visual Studio 2022 version 17.0.1"; can you update to the latest version of "Visual Studio 
2022" please?
Okt 05 15:10:11  mikekaganski: --with-visual-studio=2022
Okt 05 16:35:05  sberg: Build seems to work again after updating VS to 
17.7.4. Thanks for the help.

Re: LO 24.2 C++20 baseline

[Stephan Bergmann]

On 10/5/23 11:05, Michael Stahl wrote:

On 04/10/2023 13:56, Stephan Bergmann wrote:
(1)  Pretend that there is no issue.  Keep fingers crossed that 
"managed C++" source files compiled with /clr do not include any files 
that require a proper /std:c++20.  Or add more kludges similar to the 
above "To work around that, keep..." as needed.  (For now, until we 
eventually bump the MSVC baseline anyway, for whatever other reason.)


i think this should be enough for now?  nobody is doing any actual 
development on cli_ure anyway so we can just leave it as it is until 
some other reason for a new MSVC baseline comes along.


Unfortunately, the cli_ure code consumes other LO include files, which 
can then cause unanticipated issues like the one that caused 
 "use 
std::source_location instead of std::experimental::source_location" to 
be abandoned for now.

Re: LO 24.2 C++20 baseline

[Michael Stahl]

On 04/10/2023 13:56, Stephan Bergmann wrote:

etc.  To work around that, keep the 
 'O[U]String literals (unusable for now, C++20 only)' functionality disabled when compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler."



I see three options here going forward:

(1)  Pretend that there is no issue.  Keep fingers crossed that "managed 
C++" source files compiled with /clr do not include any files that 
require a proper /std:c++20.  Or add more kludges similar to the above 
"To work around that, keep..." as needed.  (For now, until we eventually 
bump the MSVC baseline anyway, for whatever other reason.)


i think this should be enough for now?  nobody is doing any actual 
development on cli_ure anyway so we can just leave it as it is until 
some other reason for a new MSVC baseline comes along.

Re: LO 24.2 C++20 baseline

[Julien Nabet]

>/But reading />/https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements#visual-studio-2022-system-requirements, 
/>/does it mean only devs need Windows 10 minimum or also LO users? />//No, that would only be a requirement for devs.

So no pb at all considering Visual Studio Community is free! :-)

I mean, we can expect devs to find information about building and being 
up-to-date.


Also previous versions of Windows 10 are not even in extended support of 
Microsoft so Windows 10 min shouldn't be a pb for devs.


So what would be cons here?

Re: LO 24.2 C++20 baseline

[Noel Grandin]

On Wed, 4 Oct 2023 at 17:12, Julien Nabet  wrote:

> But reading
> https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements#visual-studio-2022-system-requirements,
> does it mean only devs need Windows 10 minimum or also LO users?
>
No, that would only be a requirement for devs.

Re: LO 24.2 C++20 baseline

[Julien Nabet]

(3)  Bump the MSVC baseline requirement from VS 2019 to VS 2022.

+1

But reading 
https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements#visual-studio-2022-system-requirements, 
does it mean only devs need Windows 10 minimum or also LO users?

Re: LO 24.2 C++20 baseline

[Stephan Bergmann]

On 9/22/23 09:20, Stephan Bergmann wrote:

I just submitted

"Bump baseline to C++20" to master.  I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.)


As 
 
"Drop some newly obsolete __cplusplus version checks" revealed, "at 
least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in 
/clr mode (e.g., when compiling 
cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively 
ignored, and compilation of such source files failed with



include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class 
template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'
include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 
'rtl::OStringLiteral' requires at least '/std:c++20'
include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class 
template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'


etc.  To work around that, keep the 
 
'O[U]String literals (unusable for now, C++20 only)' functionality 
disabled when compiling /clr sources (i.e., where _MANAGED is defined) 
for that old compiler."



I see three options here going forward:

(1)  Pretend that there is no issue.  Keep fingers crossed that "managed 
C++" source files compiled with /clr do not include any files that 
require a proper /std:c++20.  Or add more kludges similar to the above 
"To work around that, keep..." as needed.  (For now, until we eventually 
bump the MSVC baseline anyway, for whatever other reason.)


(2)  Move compilation of such source files to not defining 
LIBO_INTERNAL_ONLY (so that it is treated like 3rd-party code and 
doesn't require C++11 or beyond at all).  This would require checking 
that those source files would already build fine with LIBO_INTERNAL_ONLY 
undefined.  I think instead of going down that rabbit hole of a hack it 
would be better to


(3)  Bump the MSVC baseline requirement from VS 2019 to VS 2022.

Thoughts, anyone?

Re: LO 24.2 C++20 baseline

[Stéphane Guillou]

On 25/09/2023 20:56, Stephan Bergmann wrote:

On 9/25/23 16:47, Caolán McNamara wrote:

I'm guessing that https://gerrit.libreoffice.org/c/core/+/157250 would
workaround this by just extending:

commit 5831d5f03a5ea5b89984574ffe436f38500726da
Date:   Tue Aug 1 15:37:45 2023 +0200

 Don't enable the requires clause for some Xcode Clang

which mentions the same error message, to extend from clang <= 14 to
clang <= 15


So my dim memories had not failed me :)  Thanks!

Now that the dust is settling, can I ask that the BuildingOn* wiki pages 
are checked and updated to reflect the new requirements? I'd give it a 
stab but am pretty much guaranteed to miss something, especially for 
Windows and macOS.


 * https://wiki.documentfoundation.org/Development/BuildingOnLinux
 * https://wiki.documentfoundation.org/Development/BuildingOnMac
 * https://wiki.documentfoundation.org/Development/BuildingOnWindows

Much appreciated!

--
Stéphane Guillou
Quality Assurance Analyst | The Document Foundation

Email:stephane.guil...@libreoffice.org
Mobile (France): +33 7 79 67 18 72
Matrix: @stragu:matrix.org
Fediverse: @str...@mastodon.indie.host
Web:https://stragu.gitlab.io/

Re: LO 24.2 C++20 baseline

[Miklos Vajna]

Hi,

On Mon, Sep 25, 2023 at 01:48:01PM +0300, Stephan Bergmann 
 wrote:
> Was that maybe an intermittent Clang bug?  It apparently doesn't hit the
> Jenkins Clang builds, and I don't see it with trunk Clang 18 either, but
> have dim memories that there was some issue with too-eager evaluation
> causing something like this at some point.  Do you have a way to check with
> another Clang version, to substantiate that assumption?

Yes, I can confirm downgrading to clang-12 would work around the
problem.

On Mon, Sep 25, 2023 at 12:57:56PM +0100, Caolán McNamara 
 wrote:
> On Mon, 2023-09-25 at 13:48 +0300, Stephan Bergmann wrote:
> > Was that maybe an intermittent Clang bug?  It apparently doesn't hit
> > the Jenkins Clang builds, and I don't see it with trunk Clang 18
> > either
> 
> I'm seeing it in oss-fuzz too FWIW, like
> https://oss-fuzz-build-logs.storage.googleapis.com/log-d8e659e6-8b3e-45b0-9676-ceb57d8152f4.txt

I see this got fixed with core.git commit
7f75bfd0f6b1bf4debb69e96c114e453c62685f8 (Don't enable the requires
clause for Clang 15, 2023-09-25), and that also fixed my original setup.

Thanks,

Miklos

Re: LO 24.2 C++20 baseline

[Stephan Bergmann]

On 9/25/23 16:47, Caolán McNamara wrote:

I'm guessing that https://gerrit.libreoffice.org/c/core/+/157250 would
workaround this by just extending:

commit 5831d5f03a5ea5b89984574ffe436f38500726da
Date:   Tue Aug 1 15:37:45 2023 +0200

 Don't enable the requires clause for some Xcode Clang

which mentions the same error message, to extend from clang <= 14 to
clang <= 15


So my dim memories had not failed me :)  Thanks!

Re: LO 24.2 C++20 baseline

[Caolán McNamara]

On Mon, 2023-09-25 at 08:30 +0200, Miklos Vajna wrote:
> /home/vmiklos/git/libreoffice/core-
> clang/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/util/XCl
> oneable.hpp:8:
> /home/vmiklos/git/libreoffice/core-
> clang/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInt
> erface.hpp:32:65: error: invalid application of 'sizeof' to an
> incomplete type 'animcore::(anonymous namespace)::AnimationNode'

I'm guessing that https://gerrit.libreoffice.org/c/core/+/157250 would
workaround this by just extending:

commit 5831d5f03a5ea5b89984574ffe436f38500726da
Date:   Tue Aug 1 15:37:45 2023 +0200

Don't enable the requires clause for some Xcode Clang

which mentions the same error message, to extend from clang <= 14 to
clang <= 15

Re: LO 24.2 C++20 baseline

[Caolán McNamara]

On Mon, 2023-09-25 at 13:48 +0300, Stephan Bergmann wrote:
> Was that maybe an intermittent Clang bug?  It apparently doesn't hit
> the Jenkins Clang builds, and I don't see it with trunk Clang 18
> either

I'm seeing it in oss-fuzz too FWIW, like
https://oss-fuzz-build-logs.storage.googleapis.com/log-d8e659e6-8b3e-45b0-9676-ceb57d8152f4.txt

Re: LO 24.2 C++20 baseline

[Stephan Bergmann]

On 9/25/23 08:30, Miklos Vajna wrote:

gcc-12 looks fine here, but I hit an interesting problem with clang-15
(which worked fine before pulling):

$ make animations
make -j 16 -f 
/home/vmiklos/git/libreoffice/core-clang/compilerplugins/Makefile-clang.mk 
compilerplugins
make[1]: Entering directory '/home/vmiklos/git/libreoffice/core-clang'
make[1]: Nothing to be done for 'compilerplugins'.
make[1]: Leaving directory '/home/vmiklos/git/libreoffice/core-clang'
cd /home/vmiklos/git/libreoffice/core-clang/animations && make -j 16 -rs
[CXX] animations/source/animcore/animcore.cxx
[LOC] top level modules: animations
In file included from 
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:20:
In file included from 
/home/vmiklos/git/libreoffice/core-clang/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/util/XCloneable.hpp:8:
/home/vmiklos/git/libreoffice/core-clang/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hpp:32:65:
 error: invalid application of 'sizeof' to an incomplete type 
'animcore::(anonymous namespace)::AnimationNode'
template inline constexpr auto isUnoInterfaceType = sizeof (T) && 
IsUnoInterfaceType::value;
 ^~
/home/vmiklos/git/libreoffice/core-clang/include/unotools/weakref.hxx:119:33: 
note: in instantiation of variable template specialization 
'cppu::detail::isUnoInterfaceType' requested here
 requires(!cppu::detail::isUnoInterfaceType)
 ^
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:309:44:
 note: in instantiation of template class 
'unotools::WeakReference' 
requested here
 unotools::WeakReference mxParent;
^
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:121:7:
 note: definition of 'animcore::(anonymous namespace)::AnimationNode' is not 
complete until the closing '}'
class AnimationNode final:  public AnimationNodeBase
   ^
1 error generated.
make[1]: *** 
[/home/vmiklos/git/libreoffice/core-clang/solenv/gbuild/LinkTarget.mk:340: 
/home/vmiklos/git/libreoffice/core-clang/workdir/CxxObject/animations/source/animcore/animcore.o]
 Error 1
make: *** [Makefile:121: animations] Error 2

Given that AnimationNode refers to itself, we probably can't provide a
full type for unotools::WeakReference. But then how to get around this?


Was that maybe an intermittent Clang bug?  It apparently doesn't hit the 
Jenkins Clang builds, and I don't see it with trunk Clang 18 either, but 
have dim memories that there was some issue with too-eager evaluation 
causing something like this at some point.  Do you have a way to check 
with another Clang version, to substantiate that assumption?

Re: LO 24.2 C++20 baseline

[Miklos Vajna]

Hi Stephan,

On Fri, Sep 22, 2023 at 10:20:31AM +0300, Stephan Bergmann 
 wrote:
> I just submitted
> 
> "Bump baseline to C++20" to master.

gcc-12 looks fine here, but I hit an interesting problem with clang-15
(which worked fine before pulling):

$ make animations
make -j 16 -f 
/home/vmiklos/git/libreoffice/core-clang/compilerplugins/Makefile-clang.mk 
compilerplugins
make[1]: Entering directory '/home/vmiklos/git/libreoffice/core-clang'
make[1]: Nothing to be done for 'compilerplugins'.
make[1]: Leaving directory '/home/vmiklos/git/libreoffice/core-clang'
cd /home/vmiklos/git/libreoffice/core-clang/animations && make -j 16 -rs
[CXX] animations/source/animcore/animcore.cxx
[LOC] top level modules: animations
In file included from 
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:20:
In file included from 
/home/vmiklos/git/libreoffice/core-clang/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/util/XCloneable.hpp:8:
/home/vmiklos/git/libreoffice/core-clang/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hpp:32:65:
 error: invalid application of 'sizeof' to an incomplete type 
'animcore::(anonymous namespace)::AnimationNode'
template inline constexpr auto isUnoInterfaceType = sizeof (T) && 
IsUnoInterfaceType::value;
^~
/home/vmiklos/git/libreoffice/core-clang/include/unotools/weakref.hxx:119:33: 
note: in instantiation of variable template specialization 
'cppu::detail::isUnoInterfaceType' requested here
requires(!cppu::detail::isUnoInterfaceType)
^
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:309:44:
 note: in instantiation of template class 
'unotools::WeakReference' 
requested here
unotools::WeakReference mxParent;
   ^
/home/vmiklos/git/libreoffice/core-clang/animations/source/animcore/animcore.cxx:121:7:
 note: definition of 'animcore::(anonymous namespace)::AnimationNode' is not 
complete until the closing '}'
class AnimationNode final:  public AnimationNodeBase
  ^
1 error generated.
make[1]: *** 
[/home/vmiklos/git/libreoffice/core-clang/solenv/gbuild/LinkTarget.mk:340: 
/home/vmiklos/git/libreoffice/core-clang/workdir/CxxObject/animations/source/animcore/animcore.o]
 Error 1
make: *** [Makefile:121: animations] Error 2

Given that AnimationNode refers to itself, we probably can't provide a
full type for unotools::WeakReference. But then how to get around this?

Thanks,

Miklos

Re: LO 24.2 C++20 baseline

[David Gerard]

On Sun, 24 Sept 2023 at 00:33, David Gerard  wrote:
> On Sun, 24 Sept 2023 at 00:20, David Gerard  wrote:

> > For gcc 12, as i understand it I'd have to try to bodge in the debs
> > from 22.10 (the current experimental version) or compile it from
> > source.

> sorry, I mean debs from 22.10 or later - 22.10 and 23.04 supply gcc12,
> 23.10 supplies gcc13, so I'm guessing 24.04 will supply gcc13 as well.


OK, never mind me! The following works:

sudo apt remove gcc# removes gcc-11, g++-11, build-essential
sudo apt install gcc-12 g++-12

So far it's compiling ...


- d.

Re: LO 24.2 C++20 baseline

[David Gerard]

On Sun, 24 Sept 2023 at 00:20, David Gerard  wrote:

> For gcc 12, as i understand it I'd have to try to bodge in the debs
> from 22.10 (the current experimental version) or compile it from
> source.

sorry, I mean debs from 22.10 or later - 22.10 and 23.04 supply gcc12,
23.10 supplies gcc13, so I'm guessing 24.04 will supply gcc13 as well.


- d.

Re: LO 24.2 C++20 baseline

[David Gerard]

> I just submitted
> 
> "Bump baseline to C++20" to master.  I will let it sit like that for a
> few more days, to see if anything breaks (Coverity? Linux distros'
> needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
> 202002L` etc., and before potentially unleashing the rewriting Clang
> plugin to mass-introduce uses of u""_ustr that I talked about
> yesterday at 
> 
"> If I Had C++20".

Unfortunately, this breaks the current Ubuntu LTS, 22.04 - LibreOffice
can't be compiled on it any more:

configure: error: GCC 11.4.0 is too old, must be at least GCC 12
Error running configure at /home/fun/libreoffice/autogen.sh line 321.
make: *** [Makefile:56: /home/fun/libreoffice/config_host.mk] Error 1

$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

For gcc 12, as i understand it I'd have to try to bodge in the debs
from 22.10 (the current experimental version) or compile it from
source.

The next Ubuntu LTS is 24.04.


- d.

Re: LO 24.2 C++20 baseline

[Andreas Mantke]

Hi Christian,

Am 22.09.23 um 22:15 schrieb Christian Lohmaier:

Hi Andreas,

On Fri, Sep 22, 2023 at 11:09 PM Andreas Mantke  wrote:

You can also look in config.log for more details as to why it fails

I tried with:
export CC=/usr/bin/gcc-12

That's not enough, when doing it that way you'd also have to export
CXX (one for gcc compiler, the other env for the g++ compiler)


thanks, that helps. I did two exports:

export CC=/usr/bin/gcc-11

export CXX=/usr/bin/g++-11

And autogen.sh runs without errors.

Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog:http://www.amantke.de/blog

Re: LO 24.2 C++20 baseline

[Christian Lohmaier]

Hi Andreas,

On Fri, Sep 22, 2023 at 11:09 PM Andreas Mantke  wrote:
> You can also look in config.log for more details as to why it fails
>
> I tried with:
> export CC=/usr/bin/gcc-12

That's not enough, when doing it that way you'd also have to export
CXX (one for gcc compiler, the other env for the g++ compiler)

ciao
Christian

Re: LO 24.2 C++20 baseline

[Andreas Mantke]

Hi Christian,

Am 22.09.23 um 21:25 schrieb Christian Lohmaier:

Hi Andreas,

On Fri, Sep 22, 2023 at 9:31 PM Andreas Mantke  wrote:

You can upgrade to Leap 15.5 and compiling should work again:
https://build.opensuse.org/package/show/openSUSE:Leap:15.5:Update/gcc12

unfortunately the upgrade didn't fix the issue. I got this lines at the end of 
the autogen.sh run:

checking what the C++ library is... GNU libstdc++
checking for gperf... /usr/bin/gperf
checking whether gperf is new enough... yes (3.1)
checking which libcmis to use... internal
checking whether ccache g++ supports C++20... configure: error: no
Error running configure at ./autogen.sh line 321.

Did you make sure g++ without any setup is pointing to the new gcc
version? maybe you need to add its path in front of your existing PATH
env-var or you have to use update-alternatives or similar.

You can also look in config.log for more details as to why it fails


I tried with:
export CC=/usr/bin/gcc-12

and again in a new virtual terminal with:
export CC=/usr/bin/gcc-11

and it uses the compiler from the export, but the error stays the same:

checking for sys/sdt.h... no
checking whether ccache gcc-11 supports -fstack-clash-protection... yes
checking whether ccache gcc-11 supports -mno-avx... yes
checking whether ccache gcc-11 supports atomic functions... yes
checking whether ccache g++ defines __base_class_type_info in
cxxabi.h... yes
checking whether ccache g++ defines __class_type_info in cxxabi.h... yes
checking whether ccache g++ declares __cxa_allocate_exception in
cxxabi.h... yes
checking whether ccache g++ defines __cxa_eh_globals in cxxabi.h... no
checking whether ccache g++ defines __cxa_exception in cxxabi.h... no
checking whether ccache g++ declares __cxa_get_globals in cxxabi.h... yes
checking whether ccache g++ declares __cxa_current_exception_type in
cxxabi.h... yes
checking whether ccache g++ declares __cxa_throw in cxxabi.h... yes
checking whether ccache g++ defines __si_class_type_info in cxxabi.h... yes
checking whether ccache g++ defines __vmi_class_type_info in cxxabi.h...
yes
checking what the C++ library is... GNU libstdc++
checking for gperf... /usr/bin/gperf
checking whether gperf is new enough... yes (3.1)
checking which libcmis to use... internal
checking whether ccache g++ supports C++20... configure: error: no
Error running configure at ./autogen.sh line 32

Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog:http://www.amantke.de/blog

Re: LO 24.2 C++20 baseline

[Christian Lohmaier]

Hi Andreas,

On Fri, Sep 22, 2023 at 9:31 PM Andreas Mantke  wrote:
> >
> You can upgrade to Leap 15.5 and compiling should work again:
> https://build.opensuse.org/package/show/openSUSE:Leap:15.5:Update/gcc12
>
> unfortunately the upgrade didn't fix the issue. I got this lines at the end 
> of the autogen.sh run:
>
> checking what the C++ library is... GNU libstdc++
> checking for gperf... /usr/bin/gperf
> checking whether gperf is new enough... yes (3.1)
> checking which libcmis to use... internal
> checking whether ccache g++ supports C++20... configure: error: no
> Error running configure at ./autogen.sh line 321.

Did you make sure g++ without any setup is pointing to the new gcc
version? maybe you need to add its path in front of your existing PATH
env-var or you have to use update-alternatives or similar.

You can also look in config.log for more details as to why it fails

ciao
Christian

Re: LO 24.2 C++20 baseline

[Andreas Mantke]

Hi Ilmari,

Am 22.09.23 um 18:05 schrieb Ilmari Lauhakangas:

On 22.9.2023 18.36, Andreas Mantke wrote:

Am 22.09.23 um 09:20 schrieb Stephan Bergmann:

I just submitted


"Bump baseline to C++20" to master.  I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
202002L` etc., and before potentially unleashing the rewriting Clang
plugin to mass-introduce uses of u""_ustr that I talked about
yesterday at

"If I Had C++20".


> Hi Stephan,
>
> I tried to compile from master on openSUSE 15.4 without success yet. It
> complains about the compiler (the current tool chain is gcc 7).
>
> Regards,
> Andreas

You can upgrade to Leap 15.5 and compiling should work again:
https://build.opensuse.org/package/show/openSUSE:Leap:15.5:Update/gcc12


unfortunately the upgrade didn't fix the issue. I got this lines at the
end of the autogen.sh run:

checking what the C++ library is... GNU libstdc++
checking for gperf... /usr/bin/gperf
checking whether gperf is new enough... yes (3.1)
checking which libcmis to use... internal
checking whether ccache g++ supports C++20... configure: error: no
Error running configure at ./autogen.sh line 321.


Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog:http://www.amantke.de/blog

Re: LO 24.2 C++20 baseline

[Ilmari Lauhakangas]

On 22.9.2023 18.36, Andreas Mantke wrote:

Am 22.09.23 um 09:20 schrieb Stephan Bergmann:

I just submitted

"Bump baseline to C++20" to master.  I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
202002L` etc., and before potentially unleashing the rewriting Clang
plugin to mass-introduce uses of u""_ustr that I talked about
yesterday at 


"If I Had C++20".


> Hi Stephan,
>
> I tried to compile from master on openSUSE 15.4 without success yet. It
> complains about the compiler (the current tool chain is gcc 7).
>
> Regards,
> Andreas

You can upgrade to Leap 15.5 and compiling should work again:
https://build.opensuse.org/package/show/openSUSE:Leap:15.5:Update/gcc12

Ilmari

Re: LO 24.2 C++20 baseline

[Andreas Mantke]

Hi Stephan,

I tried to compile from master on openSUSE 15.4 without success yet. It
complains about the compiler (the current tool chain is gcc 7).

Regards,
Andreas

Am 22.09.23 um 09:20 schrieb Stephan Bergmann:

I just submitted

"Bump baseline to C++20" to master.  I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
202002L` etc., and before potentially unleashing the rewriting Clang
plugin to mass-introduce uses of u""_ustr that I talked about
yesterday at 

"If I Had C++20".

LO 24.2 C++20 baseline

[Stephan Bergmann]

I just submitted

"Bump baseline to C++20" to master.  I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
202002L` etc., and before potentially unleashing the rewriting Clang
plugin to mass-introduce uses of u""_ustr that I talked about
yesterday at 

"If I Had C++20".