CalculiX is using libstdc++ (this installation is configured to use libc++)

[Chris Jones]

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.brethen at gmail.com <mailto:mark.brethen at gmail.com>
>>
>>
>>
>>> On Jul 27, 2022, at 3:49 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk 
>>> <mailto:jonesc at 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
>>