just to add. the "implicit declaration of function" issue is something a
lot of ports hit, which clang started being stricter on this (which
started with macOS11 as its a technical requirement to do this on arm).
These sorts of issues are definitely things upstream should address, by
properly declaring the method before using it. A common reason for these
errors is not including the require header with said declaration
everywhere it is required.
On 27/07/2022 1:23 pm, Chris Jones wrote:
Latest clang compilers probably default to a 'recent' c standard, unless
otherwise told. If the code in question only builds using the less
restrictive older standards, then the builds should specify this using
-std=c89 for instance..
( Note the c99 is that new, its over 20 years old now... If the code in
question *really* cannot build using that standard, it doesn't say much
for how well its been maintained. )
On 27/07/2022 1:14 pm, Mark Brethen wrote:
log for gcc build: https://pastebin.com/qbmWHm1M
<https://pastebin.com/qbmWHm1M>
log for clang12 build: https://pastebin.com/4WG7VsfA
<https://pastebin.com/4WG7VsfA>
clang14 is more restrictive on C implementation:
:info:build /usr/bin/clang -O2 -Wall -Wno-narrowing -I./
-I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src
-I../../glut-3.5/src -c -o parser.o parser.c
:info:build parser.c:85:5: error: implicit declaration of function
'DrawCommandLine' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
:info:build DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
:info:build ^
:info:build 1 error generated.
:info:build make: *** [parser.o] Error 1
Mark Brethen
mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
On Jul 27, 2022, at 3:49 AM, Chris Jones <jon...@hep.phy.cam.ac.uk
<mailto:jon...@hep.phy.cam.ac.uk>> wrote:
Please post a complete, clean, build log for the port in question.
In general GCC should not be used to build c++ (*) as doing so leads
to these c++ runtime mis-matches. You should use clang for c++ (and c
as well, although there is no runtime issues there).
cheers Chris
* The latest GCC versions now actually support building against
libc++, the clang runtime, which would make this possible in theory.
It needs support in base though
(https://github.com/macports/macports-base/pull/275
<https://github.com/macports/macports-base/pull/275>) so cannot be
used until that is available.
On 27/07/2022 1:15 am, Mark Brethen wrote:
Installing CalculiX with a clang variant is successful, however when
selecting a gcc variant:
---> Scanning binaries for linking errors
---> No broken files found.
CalculiX is using libstdc++ (this installation is configured to use
libc++)
---> Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: CalculiX @2.18+docs+examples+gcc12
Continue? [Y/n]:
Choosing ‘Y’ puts it into and endless re-install. Adding
'configure.cxx_stdlib macports-libstdc++’ seems to fix things.
1. What is causing this?
2. Should the compilers group be removed and stick with clang?
3. What changes to the portfile would need to made to permit either
compiler variant?
Thanks,
Mark
