I agree, it has become one giant mess.
One also need to remember that this current “workaround” with the header files (and commenting out libstdc++ ?) will break with the next major version release of Xcode (Xcode11) which will not come with the PKG installer for the deprecated header files.
Meanwhile, as Virtualbox does not support APFS yet it took me a while to get a VM spun up to try different install alternatives than Homebrew. The discussed option using “binary” distributions does not work on macOS 10.14 in combination with Xcode 10.2 and it is not a solution for this particular combination of software, OS and compilers. Compilation breaks with the exakt same error:
Tests-Mac:~ testos$ which gcc
/usr/local/bin/gcc
Tests-Mac:~ testos$ gcc --version
gcc (GCC) 8.2.0
Copyright © 2018 Free Software Foundation, Inc.
Detta är fri programvara, se källkoden för kopieringsvillkor. Det
finns INGEN garanti, inte ens för KÖP eller LÄMPLIGHET FÖR NÅGOT
SPECIELLT ÄNDAMÅL.
Tests-Mac:~ testos$ which g++
/usr/local/bin/g++
Tests-Mac:~ testos$ g++ --version
g++ (GCC) 8.2.0
Copyright © 2018 Free Software Foundation, Inc.
Detta är fri programvara, se källkoden för kopieringsvillkor. Det
finns INGEN garanti, inte ens för KÖP eller LÄMPLIGHET FÖR NÅGOT
SPECIELLT ÄNDAMÅL.
Tests-Mac:~ testos$ which gfortran
/usr/local/bin/gfortran
Tests-Mac:~ testos$ gfortran --version
GNU Fortran (GCC) 8.2.0
Copyright © 2018 Free Software Foundation, Inc.
Detta är fri programvara, se källkoden för kopieringsvillkor. Det
finns INGEN garanti, inte ens för KÖP eller LÄMPLIGHET FÖR NÅGOT
SPECIELLT ÄNDAMÅL.
Obtaining the gnu compiler suite versions, e.g.:
gcc -v
The C version is 8.2.0
The Fortran version is ../gcc-8.2.0/configure
8.2.0
Testing the gcc compiler:
gcc -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o testp testp.c
OK
Testing the g++ compiler:
g++ -fPIC -o testp testp.cpp
OK
Testing the gfortran compiler:
gfortran -fPIC -O0 -o testp testp.f
OK
Testing mixed C/Fortran compilation:
gcc -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o testp.c.o testp.c
gfortran -fPIC -O0 -c -o testp.f.o testp.f
gcc -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o testp testp.c.o testp.f.o -lgfortran -w
OK
Testing pointer size:
gcc -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o test_pointer_size test_pointer_size.c
Detected 64 bit operating system.
Testing flex: OK
Checking NetCDF...
Using bundled NetCDF library.
Starting NetCDF build.
Configuring NetCDF C interface (may be time-consuming)...
Compiling the NetCDF C interface (may be time-consuming)...
Configuring NetCDF Fortran interface (may be time-consuming)...
Compiling the NetCDF Fortran interface (may be time-consuming)...
NetCDF build succeeded.
Checking for zlib: OK
Checking for libbz2: OK
Testing the g++ compiler with boost:
g++ -fPIC testp.cpp -lboost_thread -lboost_system -o testp
Warning: Could not link to boost. Ensure boost-thread, boost-system and boost headers are installed.
Warning: Failed command:
g++ -fPIC -lboost_thread -lboost_system -o testp testp.cpp
Warning: Check boost.compile.err for error details.
Warning: Memembed functionality in packmol_memgen not available.
Configuring fftw-3.3 (may be time-consuming)...
fftw-3.3 configure succeeded.
Configuring XBLAS (may be time-consuming)...
XBLAS configure succeeded.
Configuring CPPTRAJ...complete.
The configuration file, config.h, was successfully created.
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/sysctl.h:83,
from StringRoutines.cpp:14:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/ucred.h:94:2: fel: ”_Atomic” är inte namnet på en typ
_Atomic u_long cr_ref; /* reference count */
^~~~~~~
make[4]: *** [StringRoutines.o] Error 1
make[3]: *** [install] Error 2
make[2]: *** [build_cpptraj] Error 2
make[1]: *** [serial] Error 2
make: *** [install] Error 2
As this affects both the binary gcc 8.2 distribution as well as the 8.3 and 7 that I tried from different sources, I don’t think switching to macports or any other source of binary distributions will solve the issue.
Compiling gcc8 under macOS 10.14.4/Xcode 10.2 (yes I tried compiling gcc8.3 from source) breaks with the same error, so I don’t see any way of using gnu compilers to build amber18 on macOS (latest release OS and Xcode) until this gets resolved.
Best regards
// Gustaf
On 3 Apr 2019, at 16:36, David A Case <david.case.rutgers.edu<mailto:david.case.rutgers.edu>> wrote:
On Wed, Apr 03, 2019, Gustaf Olsson wrote:
So this turned out to be more of a rant then I intended ....
Before Mojave, one could use almost any gnu compiler (and almost any
version > 4.6) and be as fine as one would be with Linux.
Mojave caused lots of problems, and we were arguably slow in picking up
on them, especially since a lot of developers (including me) had
switched from macports/homebrew to clang.
If you can be patient, we are working hard to get AmberTools19 (due out
this month) to work with as many combinations of compilers and OSX
variants as we can. I'll post info soon on getting release candidates for
people to try out.
[A part of the problem: just saying "mojave" or "macports" is no longer
enough. Mojave systems may or may not have altered headers; macports
has fixed some problems, so that one may need to get updated compilers,
etc.]
....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org<mailto:AMBER.ambermd.org>
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Apr 04 2019 - 06:30:04 PDT
