Re: EPICS base-3.15.9 fails to build with GCC-15

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 9/29/26 2:55 PM, Joel Sherrill wrote:

...

It is too late to back fill this in properly

Not too late because software is never done!

 but I think every project should pick a version of the language it is using and specify that in the build system. Not explicitly doing this leaves the language version to the whims of whatever gcc/llvm is installed. C11 wasn't a huge break with C99 and C17 is just a bug fix for C11. So there wasn't a huge breakage for years of C and compiler evolution. We were all just lucky. C23 has new features and keywords. GCC 15 defaults to C23. 

All well and good to say.  We are practically bound by how these standards are interpreted (or ignored) by the developers of compilers.  I think epics-base (and beyond) would have adopted C11 long ago if not for MSVC.  And the less said about the oddities of their "traditional" pre-processor, the better.  Still, there is hope for the future as we are able to drop support for these older, less complaint, toolchains.

It does help to plan for this from the start.  eg. with PVXS I explicitly target c++11, at least for gcc/clang.  Of course MSVC only started allowing targeted c++ standards at c++17.

https ://github.com/epics-base/pvxs/blob/25ca43df4db909c0b1a445fb705fc81582617625/configure/toolchain.c#L14-L18

Of course when I say c++11, what I mean is c++11 as understood by GCC 4.8, which is almost, but not quite, compliant enough for me to ignore.

We were seeing this problem with RTEMS 5 on some packages. The newer distributions had newer compilers which defaulted to newer language versions. Chris Johns added support to the RTEMS Source Builder for us to add a standard way to specify the expected language version. This addressed the problem packages for RTEMS. 

I also am a lead on an avionics software standard that specifies specific language versions and off-limits features. It is not uncommon for people to not specify any -std or specify a version not allowed in the standard and then wonder why they don't pass conformance testing. It isn't a bad reflection on EPICS -std isn't specified. It unfortunately is not something that people seem to realize is important to define as a project requirement. "EPICS shall be written in Cnn or C++nn." 

I would also add that I pushed RTEMS to be warning free for "-Wall". Once warning free with that, we went to "-Wall -Werror" and then "-Wall -Wextra". Before all the -Wextra were fixed, I added -Wno-XXX to disable specific warnings. It is thankless work but is a worthy goal.

Indeed.

https ://github.com/epics-base/epics-base/blob/e6c7dd045c2f7bb6fea43961d6a7df1328bc03f7/.github/workflows/ci-scripts-build.yml#L59-L73

https ://github.com/epics-base/pvxs/blob/25ca43df4db909c0b1a445fb705fc81582617625/.github/workflows/ci-scripts-build.yml#L50