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

[Mark Brethen]

cgx.h already had a call to extUtil.h, so I replaced it in parser.c. Build 
completed without further errors.

Thanks,
Mark



> On Jul 28, 2022, at 11:22 AM, Chris Jones  wrote:
> 
> 
> 
>> On 28 Jul 2022, at 5:21 pm, Chris Jones  wrote:
>> 
>> 
>> 
>> 
>>> On 28 Jul 2022, at 5:17 pm, Mark Brethen  wrote:
>>> 
>>> 
>>> ~ $ cd 
>>> /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
>>> src $ sudo ack DrawCommandLine
>>> Password:
>>> cgx.c
>>> 5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>>> 5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>>> 5799:  DrawCommandLine(0,0);
>>> 5803:void DrawCommandLine(char *string, int curpos)
>>> 5807:  printf(" in DrawCommandLine\n");
>>> 5874:DrawCommandLine(0,0);
>>> 
>>> cgx.h
>>> 588:void DrawCommandLine(char *string, int curpos);
>>> 
>>> parser.c
>>> 85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
>>> 
>>> 
>>> cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 
>>> 
>>> cgx.c has '#include ’
>>> 
>>> parser.c has '#include ’ only
>>> 
>>> should I add '#include ’ to parser.c or add 'void 
>>> DrawCommandLine(char *string, int curpos);’  to extUtil.h?
>> 
>> Based on the above, no, but instead add it to parser.c
> 
> Apologies, misread your reply. I would say yes to the first part.
> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com 
>>> 
>>> 
>>> 
 On Jul 27, 2022, at 8:41 PM, Joshua Root >>> > wrote:
 
 There's only one -Wimplicit-function-declaration warning in the log, so it 
 doesn't look like there's a lot that needs fixing. Just say yes to 
 function prototypes. :)
 
 - Josh

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

[Chris Jones]

> On 28 Jul 2022, at 5:21 pm, Chris Jones  wrote:
> 
> 
> 
> 
>>> On 28 Jul 2022, at 5:17 pm, Mark Brethen  wrote:
>>> 
>> 
>> ~ $ cd 
>> /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
>> src $ sudo ack DrawCommandLine
>> Password:
>> cgx.c
>> 5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>> 5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>> 5799:  DrawCommandLine(0,0);
>> 5803:void DrawCommandLine(char *string, int curpos)
>> 5807:  printf(" in DrawCommandLine\n");
>> 5874:DrawCommandLine(0,0);
>> 
>> cgx.h
>> 588:void DrawCommandLine(char *string, int curpos);
>> 
>> parser.c
>> 85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
>> 
>> 
>> cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 
>> 
>> cgx.c has '#include ’
>> 
>> parser.c has '#include ’ only
>> 
>> should I add '#include ’ to parser.c or add 'void 
>> DrawCommandLine(char *string, int curpos);’  to extUtil.h?
> 
> Based on the above, no, but instead add it to parser.c

Apologies, misread your reply. I would say yes to the first part.

>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jul 27, 2022, at 8:41 PM, Joshua Root  wrote:
>>> 
>>> There's only one -Wimplicit-function-declaration warning in the log, so it 
>>> doesn't look like there's a lot that needs fixing. Just say yes to function 
>>> prototypes. :)
>>> 
>>> - Josh
>> 

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

[Chris Jones]

> On 28 Jul 2022, at 5:17 pm, Mark Brethen  wrote:
> 
> 
> ~ $ cd 
> /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
> src $ sudo ack DrawCommandLine
> Password:
> cgx.c
> 5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
> 5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
> 5799:  DrawCommandLine(0,0);
> 5803:void DrawCommandLine(char *string, int curpos)
> 5807:  printf(" in DrawCommandLine\n");
> 5874:DrawCommandLine(0,0);
> 
> cgx.h
> 588:void DrawCommandLine(char *string, int curpos);
> 
> parser.c
> 85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
> 
> 
> cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 
> 
> cgx.c has '#include ’
> 
> parser.c has '#include ’ only
> 
> should I add '#include ’ to parser.c or add 'void DrawCommandLine(char 
> *string, int curpos);’  to extUtil.h?

Based on the above, no, but instead add it to parser.c
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 27, 2022, at 8:41 PM, Joshua Root  wrote:
>> 
>> There's only one -Wimplicit-function-declaration warning in the log, so it 
>> doesn't look like there's a lot that needs fixing. Just say yes to function 
>> prototypes. :)
>> 
>> - Josh
> 

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

[Mark Brethen]

~ $ cd 
/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
src $ sudo ack DrawCommandLine
Password:
cgx.c
5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
5799:  DrawCommandLine(0,0);
5803:void DrawCommandLine(char *string, int curpos)
5807:  printf(" in DrawCommandLine\n");
5874:DrawCommandLine(0,0);

cgx.h
588:void DrawCommandLine(char *string, int curpos);

parser.c
85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);


cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 

cgx.c has '#include ’

parser.c has '#include ’ only

should I add '#include ’ to parser.c or add 'void DrawCommandLine(char 
*string, int curpos);’  to extUtil.h?

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 8:41 PM, Joshua Root  wrote:
> 
> There's only one -Wimplicit-function-declaration warning in the log, so it 
> doesn't look like there's a lot that needs fixing. Just say yes to function 
> prototypes. :)
> 
> - Josh

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

[Ryan Schmidt]

On Jul 27, 2022, at 07:41, Mark Brethen wrote:
> 
> As the source does not use configure, I pass the compiler args:
> 
> pre-build {
>build.args-appendCXX=${configure.cxx} \
> CC=${configure.cc}
> }
> 
> For reasons I don’t understand, If I don’t put it in a pre-build override 
> it’s ignored.

Certainly not ignored, but conceivably not doing what you wanted.

If you just write:

   build.args-appendCXX=${configure.cxx} \
CC=${configure.cc}

outside of any phase, that takes effect the moment the Portfile is parsed. This 
will use whatever compiler value MacPorts chooses, modulated by any 
compiler.blacklist or similar setting you have set on lines before that line.

However, you mentioned the compilers portgroup, which allows you to set a 
compiler by choosing a variant. Variant blocks are parsed after the main part 
of the Portfile, so if you want any compiler modifications that might have been 
made by a variant block to be honored by these build.args, you have to do as 
you did and wait to set the build.args until right before you use them, e.g. in 
a pre-build block.

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

[Joshua Root]

There's only one -Wimplicit-function-declaration warning in the log, so 
it doesn't look like there's a lot that needs fixing. Just say yes to 
function prototypes. :)


- Josh

On 2022-7-28 07:12 , Mark Brethen wrote:

 1.
:debug:configure Preferred compilers: clang macports-clang-14
macports-clang-13 macports-clang-12 macports-clang-11
macports-clang-10 macports-clang-9.0


It does build with macports-clang*: https://pastebin.com/vmKFHatf 





Thanks,
Mark



On Jul 27, 2022, at 10:39 AM, Mark Brethen > wrote:


I suppose it dies on the first error… there could be others 
downstream, which turns into an exhaustive cycle.



Mark Brethen
mark.bret...@gmail.com 



On Jul 27, 2022, at 9:58 AM, Chris Jones > wrote:


patch the code to remove the improper implicit declaration

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

[Mark Brethen]

:debug:configure Preferred compilers: clang macports-clang-14 macports-clang-13 macports-clang-12 macports-clang-11 macports-clang-10 macports-clang-9.0It does build with macports-clang*: https://pastebin.com/vmKFHatf

Portfile
Description: Binary data

Thanks,Mark


On Jul 27, 2022, at 10:39 AM, Mark Brethen  wrote:I suppose it dies on the first error… there could be others downstream, which turns into an exhaustive cycle.
Mark Brethenmark.bret...@gmail.com


On Jul 27, 2022, at 9:58 AM, Chris Jones  wrote:patch the code to remove the improper implicit declaration

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

[Mark Brethen]

I suppose it dies on the first error… there could be others downstream, which 
turns into an exhaustive cycle.


Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 9:58 AM, Chris Jones  wrote:
> 
> patch the code to remove the improper implicit declaration

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

[Chris Jones]

oK, so that didn't help...

The better fix is anyway to patch the code to remove the improper 
implicit declaration, so suggest you look more to that direction.


On 27/07/2022 3:53 pm, Mark Brethen wrote:

Clang12 w/-std=c99:
:info:build parser.c:85:5: warning: implicit declaration of function 
'DrawCommandLine' is invalid in C99 [-Wimplicit-function-declaration]


Clang14 w/-std=c89:
:info:build /usr/bin/clang -std=c89 -Os -arch x86_64 -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' [-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 



On Jul 27, 2022, at 7:23 AM, 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..

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

[Mark Brethen]

Clang12 w/-std=c99: 
:info:build parser.c:85:5: warning: implicit declaration of function 
'DrawCommandLine' is invalid in C99 [-Wimplicit-function-declaration]

Clang14 w/-std=c89:
:info:build /usr/bin/clang -std=c89 -Os -arch x86_64 -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' [-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



> On Jul 27, 2022, at 7:23 AM, 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..

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

[Mark Brethen]

I tried setting CFLAGS in he pre-build before, which negates the includes in 
the patch, and the build fails.

:info:build Executing:  cd 
"/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src"
 && /usr/bin/make -j4 -w CXX=/usr/bin/clang++ CC=/usr/bin/clang CFLAGS="-Os 
-arch x86_64" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch 
x86_64" 

:info:build In file included from adjustMidsideNode.c:31:
:info:build In file included from ./cgx.h:25:
:info:build ./extUtil.h:40:12: fatal error: 'GL/glut_cgx.h' file not found
:info:build   #include 
:info:build^~~

Either I add those to the patch or put everything in the pre-build.

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 7:52 AM, Chris Jones  wrote:
> 
> Then you should at least set these as well pre-build
> 
> CFLAGS="${configure.cflags} [get_canonical_archflags cc]"
> 
> LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"
> 
> The info in CXXFLAGS should also be passed in some way as well
> 
> CXXFLAGS="${configure.cxxflags} [get_canonical_archflags cxx]"
> 
> If the makefile currently does not use this, it should be added.

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

[Chris Jones]

On 27/07/2022 1:49 pm, Mark Brethen wrote:
As you can see in the makefile (post-patch), it only makes use of CFLAGS 
and LDFLAGS.


Then you should at least set these as well pre-build

CFLAGS="${configure.cflags} [get_canonical_archflags cc]"

LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"

The info in CXXFLAGS should also be passed in some way as well

CXXFLAGS="${configure.cxxflags} [get_canonical_archflags cxx]"

If the makefile currently does not use this, it should be added.




Mark Brethen
mark.bret...@gmail.com 



On Jul 27, 2022, at 7:41 AM, Joshua Root > wrote:


It's also not passing in the MacPorts CFLAGS, CXXFLAGS, and LDFLAGS. 
If it's a handcrafted Makefile, it may need some modification to even 
accept and use those.

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

[Mark Brethen]

As you can see in the makefile (post-patch), it only makes use of CFLAGS and LDFLAGS.

Makefile
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Jul 27, 2022, at 7:41 AM, Joshua Root  wrote:It's also not passing in the MacPorts CFLAGS, CXXFLAGS, and LDFLAGS. If it's a handcrafted Makefile, it may need some modification to even accept and use those.

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

[Mark Brethen]

As the source does not use configure, I pass the compiler args:

pre-build {
build.args-appendCXX=${configure.cxx} \
 CC=${configure.cc}
}

For reasons I don’t understand, If I don’t put it in a pre-build override it’s 
ignored.

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 7:30 AM, Chris Jones  wrote:
> 
> 
> 
> On 27/07/2022 1:14 pm, Mark Brethen wrote:
>> log for gcc build: https://pastebin.com/qbmWHm1M 
>> <https://pastebin.com/qbmWHm1M>
> 
> above shows gcc is indeed being used to build c++ code
> 
> :info:build /opt/local/bin/g++-mp-12  userFunction.o  AsplitA.o AsplitL.o 
> adjustMidsideNode.o compareStrings.o XFunktions.o badelems.o bodyMesh2.o 
> bsort.o bsortf.o bsorti.o calcNormalen.o calcPrinc.o calcPvector.o 
> calcWeight.o checkIfNumber.o cgx.o compare.o copyEntity.o corrad.o dataGeo.o 
> dataMesh.o defineEntity.o dispLists.o elemChecker.o extFunktions.o extGL.o 
> fillBody2.o frecord.o foamFaces.o gl3grades.o getGeoDataTria.o graph.o 
> ifind.o iinsert.o improveBadTr3.o improveMesh.o iniMeshData.o intpol.o 
> intpol2.o intpol3.o iremove.o linelength.o m_copy.o m_sub.o mergEntity.o 
> mesh2d.o meshSet.o meshSurf.o messages.o near3d.o normdist.o nurbl2seq.o 
> orient.o p_angle.o parser.o pickFunktions.o plotFunktions.o readAnsysList.o 
> readEdges.o readfrd.o readFoam.o readStdCmap.o readStl.o readccx.o readDuns.o 
> readNastran.o readNG.o readTG.o readIsaac.o readstep.o readWf.o rectcyl.o 
> renumberfrd.o selectDisplayFaces.o sendMpc.o sendSet.o setFunktions.o 
> shapeFunctions.o spline.o splitElementsToTets.o stof.o stoi.o stopClock.o 
> stos.o strfind.o strsplt.o sins.o surfMesh2.o sword.o trackball.o v_distA.o 
> v_rec2cyl.o v_add.o v_angle.o v_angle_ref.o v_betrag.o v_matmult.o v_norm.o 
> v_prod.o v_result.o v_scal.o v_rot.o v_sprod.o m_prod.o m_prodtr.o 
> write2aba.o write2ansys.o write2aster.o write2darwin.o write2dolfyn.o 
> write2isaac.o write2duns.o write2frd.o write2foam.o write2nas.o 
> write2samcef.o write2tochnog.o writefbd.o writebp.o contact.o 
> makeTriFromElems.o uselibSNL.cpp generateTet.cpp ../../libSNL/src/*.cpp  -O2 
> -Wall -Wno-narrowing -I./ -I/opt/local/include -I/opt/local/include/GL 
> -I../../libSNL/src -I../../glut-3.5/src  -L/opt/local/lib -lGL -lGLU -lglut 
> -lX11 -lXi -lXmu -lXext -lXt -lSM -lICE -lm -lpthread -o  cgx
> 
> this is not really supported. Your time would be better spent fixing the 
> issues with using clang++ to build.
> 
> Chris
> 
>> 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 >> <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

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

[Joshua Root]

On 2022-7-27 22:30 , Chris Jones wrote:



On 27/07/2022 1:14 pm, Mark Brethen wrote:
log for gcc build: https://pastebin.com/qbmWHm1M 



above shows gcc is indeed being used to build c++ code

:info:build /opt/local/bin/g++-mp-12  userFunction.o  AsplitA.o 
AsplitL.o adjustMidsideNode.o compareStrings.o XFunktions.o badelems.o 
bodyMesh2.o bsort.o bsortf.o bsorti.o calcNormalen.o calcPrinc.o 
calcPvector.o calcWeight.o checkIfNumber.o cgx.o compare.o copyEntity.o 
corrad.o dataGeo.o dataMesh.o defineEntity.o dispLists.o elemChecker.o 
extFunktions.o extGL.o fillBody2.o frecord.o foamFaces.o gl3grades.o 
getGeoDataTria.o graph.o ifind.o iinsert.o improveBadTr3.o improveMesh.o 
iniMeshData.o intpol.o intpol2.o intpol3.o iremove.o linelength.o 
m_copy.o m_sub.o mergEntity.o mesh2d.o meshSet.o meshSurf.o messages.o 
near3d.o normdist.o nurbl2seq.o orient.o p_angle.o parser.o 
pickFunktions.o plotFunktions.o readAnsysList.o readEdges.o readfrd.o 
readFoam.o readStdCmap.o readStl.o readccx.o readDuns.o readNastran.o 
readNG.o readTG.o readIsaac.o readstep.o readWf.o rectcyl.o 
renumberfrd.o selectDisplayFaces.o sendMpc.o sendSet.o setFunktions.o 
shapeFunctions.o spline.o splitElementsToTets.o stof.o stoi.o 
stopClock.o stos.o strfind.o strsplt.o sins.o surfMesh2.o sword.o 
trackball.o v_distA.o v_rec2cyl.o v_add.o v_angle.o v_angle_ref.o 
v_betrag.o v_matmult.o v_norm.o v_prod.o v_result.o v_scal.o v_rot.o 
v_sprod.o m_prod.o m_prodtr.o write2aba.o write2ansys.o write2aster.o 
write2darwin.o write2dolfyn.o write2isaac.o write2duns.o write2frd.o 
write2foam.o write2nas.o write2samcef.o write2tochnog.o writefbd.o 
writebp.o contact.o makeTriFromElems.o uselibSNL.cpp generateTet.cpp 
../../libSNL/src/*.cpp  -O2 -Wall -Wno-narrowing -I./ 
-I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
-I../../glut-3.5/src  -L/opt/local/lib -lGL -lGLU -lglut -lX11 -lXi 
-lXmu -lXext -lXt -lSM -lICE -lm -lpthread -o  cgx


this is not really supported. Your time would be better spent fixing the 
issues with using clang++ to build.


It's also not passing in the MacPorts CFLAGS, CXXFLAGS, and LDFLAGS. If 
it's a handcrafted Makefile, it may need some modification to even 
accept and use those.


- Josh

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

[Chris Jones]

On 27/07/2022 1:14 pm, Mark Brethen wrote:
log for gcc build: https://pastebin.com/qbmWHm1M 
<https://pastebin.com/qbmWHm1M>


above shows gcc is indeed being used to build c++ code

:info:build /opt/local/bin/g++-mp-12  userFunction.o  AsplitA.o 
AsplitL.o adjustMidsideNode.o compareStrings.o XFunktions.o badelems.o 
bodyMesh2.o bsort.o bsortf.o bsorti.o calcNormalen.o calcPrinc.o 
calcPvector.o calcWeight.o checkIfNumber.o cgx.o compare.o copyEntity.o 
corrad.o dataGeo.o dataMesh.o defineEntity.o dispLists.o elemChecker.o 
extFunktions.o extGL.o fillBody2.o frecord.o foamFaces.o gl3grades.o 
getGeoDataTria.o graph.o ifind.o iinsert.o improveBadTr3.o improveMesh.o 
iniMeshData.o intpol.o intpol2.o intpol3.o iremove.o linelength.o 
m_copy.o m_sub.o mergEntity.o mesh2d.o meshSet.o meshSurf.o messages.o 
near3d.o normdist.o nurbl2seq.o orient.o p_angle.o parser.o 
pickFunktions.o plotFunktions.o readAnsysList.o readEdges.o readfrd.o 
readFoam.o readStdCmap.o readStl.o readccx.o readDuns.o readNastran.o 
readNG.o readTG.o readIsaac.o readstep.o readWf.o rectcyl.o 
renumberfrd.o selectDisplayFaces.o sendMpc.o sendSet.o setFunktions.o 
shapeFunctions.o spline.o splitElementsToTets.o stof.o stoi.o 
stopClock.o stos.o strfind.o strsplt.o sins.o surfMesh2.o sword.o 
trackball.o v_distA.o v_rec2cyl.o v_add.o v_angle.o v_angle_ref.o 
v_betrag.o v_matmult.o v_norm.o v_prod.o v_result.o v_scal.o v_rot.o 
v_sprod.o m_prod.o m_prodtr.o write2aba.o write2ansys.o write2aster.o 
write2darwin.o write2dolfyn.o write2isaac.o write2duns.o write2frd.o 
write2foam.o write2nas.o write2samcef.o write2tochnog.o writefbd.o 
writebp.o contact.o makeTriFromElems.o uselibSNL.cpp generateTet.cpp 
../../libSNL/src/*.cpp  -O2 -Wall -Wno-narrowing -I./ 
-I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
-I../../glut-3.5/src  -L/opt/local/lib -lGL -lGLU -lglut -lX11 -lXi 
-lXmu -lXext -lXt -lSM -lICE -lm -lpthread -o  cgx


this is not really supported. Your time would be better spent fixing the 
issues with using clang++ to build.


Chris



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 <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

Re: 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.bret...@gmail.com <mailto:mark.bret...@gmail.com>



On Jul 27, 2022, at 3:49 AM, Chris Jones <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

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

[Chris Jones]

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 <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

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

[Mark Brethen]

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



> On Jul 27, 2022, at 3:49 AM, Chris Jones  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) 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

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

[Chris Jones]

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) 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

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

[Mark Brethen]

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 orderYou can always run 'port rev-upgrade' again to fix errors.The following ports will be rebuilt: CalculiX @2.18+docs+examples+gcc12Continue? [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?

Portfile
Description: Binary data

Thanks,Mark