I personally only use native clang or gcc bundled in gfortran binary for
macos. Both works well for me. I am not sure if we need macport or brew
anymore.
Hai
On Tue, Apr 2, 2019 at 9:24 AM Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
> So after a couple of frustrating runs I have tried to patch the source and
> compile my own gcc8 version from source, while pushing the error further
> and further away I can’t compile gcc8 because of the following error:
>
> In file included from /usr/include/sys/sysctl.h:83,
> from ../../gcc/config/darwin-driver.c:30:
> /usr/include/sys/ucred.h:94:2: error: ‘_Atomic’ does not name a type
> _Atomic u_long cr_ref; /* reference count */
> ^~~~~~~
> make[3]: *** [darwin-driver.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> rm gcc.pod gfortran.pod
> make[2]: *** [all-stage2-gcc] Error 2
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
>
> Looks familiar? "error: ‘_Atomic’ does not name a type”. So apparently
> the supplied patch did not solve this issue as suggested either. Well, at
> least clang works fairly well with little modification for now. Anyone
> tried a GNU (gcc/gfortran) installation (no clang) using MacPorts compilers
> yet? Otherwise I’ll put this on my list of things to try.
>
> Best regards
> // Gustaf
>
> > On 2 Apr 2019, at 09:27, Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
> >
> >> Do you have a CXX envinroment variable set, and if so, to what?
> >> ...thx...dac
> >
> >
> > I did not, though setting it does not change anything, unfortunately.
> >
> >> This actually appears to be the result of Apple mucking with header
> >> files and is GNU/C++ specific on Mojave; see
> >>
> https://apple.stackexchange.com/questions/355049/compilation-error-with-mojave-error-atomic-does-not-name-a-type
> .
> >
> > So the way that I am reeding this, it stems from an issue with the
> homebrew gcc installation? I would either need to compile gcc myself from
> source implementing the patch as indicated or find a way to configure the
> amber cpptraj compilation without c++11 support? The first option would
> only be “simple enough” if the patched version of gcc works and I can push
> it to the homebrew repository fo re-use. The latter might work “out of the
> box” though it is annoying.
> >
> >> This seems like you're using the standalone cpptraj configure from
> >> inside AmberTools maybe? If so, you should execute it the same way
> >> $AMBERHOME/AmberTools/src/configure2 does, specifying
> >> '--with-netcdf=$AMBERHOME' etc so it knows where to get NetCDF etc
> >> (search for 'Configure CPPTRAJ' in configure2).
> >>
> >> -Dan
> >
> > I was trying to build the standalone version of cpptraj from GitHub
> independently from amber to see if it made any difference though I did not
> manage to get cpptraj to find the system installed NetCDF version that I
> have. Though maybe now I can specify using
> --with-netcdf=/location/of/netcdf to completely ignore the amber18 folder
> and have an isolated compilation of cpptraj?
> >
> > Best regards
> > // Gustaf
> >
> >
> >> On 1 Apr 2019, at 17:18, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Apr 1, 2019 at 8:04 AM Gustaf Olsson <gustaf.olsson.lnu.se>
> wrote:
> >>> CXX StringRoutines.cpp
> >>> 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:
> error: '_Atomic' does not name a type
> >>> _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
> >>>
> >>> This is seemingly an issue with CPPTRAJ that does not show up when
> compiling using clang so I am assuming this is somehow related to gcc. Now,
> I know that macOS does not make it easy compiling though I am curious why
> something would be sourced from the Xcode CLT when not using the apple
> compiler.
> >>
> >> This actually appears to be the result of Apple mucking with header
> >> files and is GNU/C++ specific on Mojave; see
> >>
> https://apple.stackexchange.com/questions/355049/compilation-error-with-mojave-error-atomic-does-not-name-a-type
> .
> >> I'm not sure what the proper workaround is; maybe disabling C++11 for
> >> cpptraj? Can you try configuring cpptraj standalone (either via
> >> $AMBERHOME/AmberTools/src/cpptraj or via the GitHub version) with
> >> -noc++11?
> >>
> >>>
> >>> Trying to build from git, I get a NetCDF test error:
> >>>
> >>> Checking NetCDF:
> >>> Test compile failed: g++ -Wall -O3 -std=gnu++11 -o testp
> testp.cpp -lnetcdf
> >>> Error follows:
> >>> testp.cpp:2:10: fatal error: netcdf.h: No such file or directory
> >>> #include "netcdf.h"
> >>
> >> This seems like you're using the standalone cpptraj configure from
> >> inside AmberTools maybe? If so, you should execute it the same way
> >> $AMBERHOME/AmberTools/src/configure2 does, specifying
> >> '--with-netcdf=$AMBERHOME' etc so it knows where to get NetCDF etc
> >> (search for 'Configure CPPTRAJ' in configure2).
> >>
> >> -Dan
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> 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 Tue Apr 02 2019 - 06:30:05 PDT
