On Thu, 1 Aug 2024, Ilija Tovilo wrote:
Hence, it seems like it would be ok to bump our C compiler requirement
to C11. We'd like to make this change before beta 1 if there are no
objections.
How would you enforce that, through configure?
FWIW, I have just tried compiling Xdebug with -std=c2x (C23) and that
caused me one trivial required change:
cheers,
Derick
On 05.08.2024 at 12:49, Derick Rethans wrote:
On Thu, 1 Aug 2024, Ilija Tovilo wrote:
Hence, it seems like it would be ok to bump our C compiler requirement
to C11. We'd like to make this change before beta 1 if there are no
objections.How would you enforce that, through configure?
In my opinion, there is no *need* to enforce this requirement. Just
having documentation should be sufficient. Users with an old compilerr
will notice issues (i.e. build failures), and even if they don't care to
look up the docs, they will file a ticket, and that can quickly be
closed pointing to the relevant documentation.
Christoph
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
On 05.08.2024 at 12:49, Derick Rethans wrote:
> On Thu, 1 Aug 2024, Ilija Tovilo wrote:
>
>> Hence, it seems like it would be ok to bump our C compiler
>> requirement to C11. We'd like to make this change before beta 1 if
>> there are no objections.
>
> How would you enforce that, through configure?In my opinion, there is no *need* to enforce this requirement. Just
having documentation should be sufficient. Users with an old
compilerr will notice issues (i.e. build failures), and even if they
don't care to look up the docs, they will file a ticket, and that can
quickly be closed pointing to the relevant documentation.
Instead of having to deal with tickets, wouldn't be be easier if the
compiler they used works with the features that we are using? That could
instantly provide a link to the documentation saving all of us time.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social
On Mon, Aug 5, 2024, 10:03 PM Derick Rethans <derick@php.net> wrote:
Instead of having to deal with tickets, wouldn’t be be easier if the
compiler they used works with the features that we are using? That could
instantly provide a link to the documentation saving all of us time.
it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11 compliant (not 4.7).
As of windows, it will be dependent on the vc version used by the php minor branch where it may be introduced.
That being said, I am not sure if the reason mentioned for using c11 in the initial post is used in external extensions (included headers etc), but at least on linux (or similar), an ext can be compiled with any version.
On windows, we can’t, mainly for memory management issues (alloc/realloc or freed using different crt). It is possible but too many extensions, also in core, cause issues.
best,
Pierre
On 05.08.2024 at 16:59, Derick Rethans wrote:
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
In my opinion, there is no *need* to enforce this requirement. Just
having documentation should be sufficient. Users with an old
compilerr will notice issues (i.e. build failures), and even if they
don't care to look up the docs, they will file a ticket, and that can
quickly be closed pointing to the relevant documentation.Instead of having to deal with tickets, wouldn't be be easier if the
compiler they used works with the features that we are using? That could
instantly provide a link to the documentation saving all of us time.
Note that I'm not *against* checking C11 support during configure. If
there is a respective feature test readily available for autoconf –
great. Otherwise it might be sufficient to check for the definition and
value of __STDC_VERSION__. However, I don't think it would be a good
idea to test for certain compilers and their versions; that list might
need more maintaince than catering to a couple of bug reports. Before
we go down that route, we may be better off just documenting the
requirement.
Christoph
On 05.08.2024 at 17:42, Pierre Joye wrote:
On Mon, Aug 5, 2024, 10:03 PM Derick Rethans <derick@php.net> wrote:
Instead of having to deal with tickets, wouldn't be be easier if the
compiler they used works with the features that we are using? That could
instantly provide a link to the documentation saving all of us time.it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11
compliant (not 4.7).
But what about other compilers we support on non Windows platforms
currently, like clang, Apple's clang, Solaris Studio and maybe some more
we don't even know about.
As of windows, it will be dependent on the vc version used by the php minor
branch where it may be introduced.
It's supposed to be introduced as of PHP 8.4.0, which already uses VS
17, although MSVC supports C11 as of VS 16.5 (while it never claimed to
support C99). So in practise, even those still building their own
Windows binaries with Visual Studio 2019 should not be affected.
That being said, I am not sure if the reason mentioned for using c11 in the
initial post is used in external extensions (included headers etc), but at
least on linux (or similar), an ext can be compiled with any version.
I somewhat doubt that; we're using a couple of C99 features (like mixed
declarations and statements) in the core for a couple of years (IIRC, as
of PHP 8.0.0), and extensions may do this with their own code, or might
be forced to include public php-src headers which may use some C99
features. This may not be an issue with any C compilers actually still
in use, but can be sure about that?
And some extensions even require C++ support.
Christoph
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
On 05.08.2024 at 17:42, Pierre Joye wrote:
> On Mon, Aug 5, 2024, 10:03 PM Derick Rethans <derick@php.net> wrote:
>
>> Instead of having to deal with tickets, wouldn't be be easier if
>> the compiler they used works with the features that we are using?
>> That could instantly provide a link to the documentation saving all
>> of us time.
>
> it is significantly easier at configure time. Gcc 4.9 is (almost)
> fully c11 compliant (not 4.7).But what about other compilers we support on non Windows platforms
currently, like clang, Apple's clang, Solaris Studio and maybe some
more we don't even know about.
Normal clang supports the same flag. Apple clang potentially too, but
not currently:
https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html
— it could be outdated information though. I don't have a mac to test.
But it's just possible to check for the flag for compilers that we *do*
know about. And by checking for it and showing a warning, we make
people's lives easire.
cheers,
Derick
On 06.08.2024 at 13:26, Derick Rethans wrote:
Normal clang supports the same flag. Apple clang potentially too, but
not currently:
Clang Compiler User's Manual
— it could be outdated information though. I don't have a mac to test.But it's just possible to check for the flag for compilers that we *do*
know about. And by checking for it and showing a warning, we make
people's lives easire.
Not sure about which flag you are talking, but anyway see
<php.internals: Re: Require C11 in PHP 8.4. I.e. I'm fine with a
feature test, but wouldn't want to check for individual compiler
versions (although I have no hard feelings about that).
Christoph
On 6 Aug 2024, at 18:26, Derick Rethans derick@php.net wrote:
Normal clang supports the same flag. Apple clang potentially too, but
not currently:
https://opensource.apple.com/source/clang/clang-23/clang/tools/clang/docs/UsersManual.html
— it could be outdated information though. I don’t have a mac to test.
I believe that is extrmely outdated, based on the other listings on https://opensource.apple.com/source/clang/ and the listings by macOS version on https://opensource.apple.com/releases/
To be certain, I fired up my old macOS Sierra VM again (which reports as having Clang 9) and tried a simple clang -std=c11 foo.c - it doesn’t complain about c11 being invalid (which it does if I try say -std=c17)
Is there a specific branch in the repo (or in a fork) that already uses the required features? I can try to compile on this VM, to confirm whether it actually works.
Cheers
Stephen
On Mon, 5 Aug 2024 at 19:15, Christoph M. Becker <cmbecker69@gmx.de> wrote:
But what about other compilers we support on non Windows platforms
currently, like clang, Apple's clang, Solaris Studio and maybe some more
we don't even know about.
Might be worth noting here that from what I've tested so far that PHP
cannot be built currently with Solaris Studio compiler and most likely
any other compiler out of the range of MSVC, GCC and Clang (including
the AppleClang). There are errors in the configure steps due to not
properly checked linker flags and there are lots of warnings and
errors produced during the make step. So, basically the list of
"supported" and heavily tested compilers is at this point: GCC and
Clang.
I find this strange, but it also makes sense to not be able to support
a wide variety of compilers without having additional CI builds.
A nice list of "relevant" compilers from the build system point of
view for some overview:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html
On Tue, Aug 6, 2024 at 12:10 AM Christoph M. Becker <cmbecker69@gmx.de> wrote:
On 05.08.2024 at 17:42, Pierre Joye wrote:
> On Mon, Aug 5, 2024, 10:03 PM Derick Rethans <derick@php.net> wrote:
>
>> Instead of having to deal with tickets, wouldn't be be easier if the
>> compiler they used works with the features that we are using? That could
>> instantly provide a link to the documentation saving all of us time.
>
> it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11
> compliant (not 4.7).But what about other compilers we support on non Windows platforms
currently, like clang, Apple's clang, Solaris Studio and maybe some more
we don't even know about.
Sorry, I meant to actually check if that feature is supported with
AC_COMPILE_*. It is painful but has proven to be the only reliable
way.
As gcc or VCC can be slightly more trusted using their versions, the
other, especially on MacOs, can't be trusted, ever. Let alone on other
OSes I still wonder why we support them for latest php 8 versions
(solaris f.e.).
> As of windows, it will be dependent on the vc version used by the php minor
> branch where it may be introduced.It's supposed to be introduced as of PHP 8.4.0, which already uses VS
17, although MSVC supports C11 as of VS 16.5 (while it never claimed to
support C99). So in practise, even those still building their own
Windows binaries with Visual Studio 2019 should not be affected.> That being said, I am not sure if the reason mentioned for using c11 in the
> initial post is used in external extensions (included headers etc), but at
> least on linux (or similar), an ext can be compiled with any version.I somewhat doubt that; we're using a couple of C99 features (like mixed
declarations and statements) in the core for a couple of years (IIRC, as
of PHP 8.0.0), and extensions may do this with their own code, or might
be forced to include public php-src headers which may use some C99
features. This may not be an issue with any C compilers actually still
in use, but can be sure about that?
We can't :).
To my understanding the challenges are the extensions maintainers. On
Windows it is a controlled environment. We had similar discussions
back then when we dropped VC6, which was a much bigger step. I would
prefer to go with what makes your work easier than trying to keep
older VC support for the latest release, in case we decide to support
a minimum VC version for valid reasons. atomic support seems to be
one, the header one, I am very doubtful about it as something worth
the troubles :). This is being only about windows, that's indeed not
valid for any linux/*bsd/*wrt/etc.
cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
On 06.08.2024 at 15:01, Peter Kokot wrote:
On Mon, 5 Aug 2024 at 19:15, Christoph M. Becker <cmbecker69@gmx.de> wrote:
But what about other compilers we support on non Windows platforms
currently, like clang, Apple's clang, Solaris Studio and maybe some more
we don't even know about.Might be worth noting here that from what I've tested so far that PHP
cannot be built currently with Solaris Studio compiler and most likely
any other compiler out of the range of MSVC, GCC and Clang (including
the AppleClang). There are errors in the configure steps due to not
properly checked linker flags and there are lots of warnings and
errors produced during the make step. So, basically the list of
"supported" and heavily tested compilers is at this point: GCC and
Clang.
Oh! I wasn't aware of that.
I find this strange, but it also makes sense to not be able to support
a wide variety of compilers without having additional CI builds.
Well, users of other compilers could file bug reports, and we could
possibly address them even without setting up another CI build (it seems
those not using Github runners are already not really helpful).
A nice list of "relevant" compilers from the build system point of
view for some overview:
CMAKE_<LANG>_COMPILER_ID — CMake 3.30.2 Documentation
Interesting, thanks! While I would not have expected that php-src can
be built on all of these, at least I thought some of these were supported.
Christoph