[Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments?
Bernard Kelly
physicsbeany at gmail.com
Tue Nov 21 21:14:14 CST 2023
Hi Erik, Roland, et al.
Problem resolved. It turns out the issue was with my local XCode
installation. I was on a beta version of XCode 15.x, which needed to be
upgraded (and I then had to reinstall Macports).
One lingering issue: the linker that comes with XCode 15 has some different
behavior that still messes up compilation. I have to add "-ld_classic" to
my compiler flags to fix it.
Thanks for the advice, Bernard
On Fri, Nov 17, 2023 at 9:26 AM Erik Schnetter <schnetter at gmail.com> wrote:
> In Cactus, "LD" needs to point to a compiler driver (e.g. "g++"), not
> to a linker. You should see a very different error message when you
> set "LD" to a linker. (Or maybe the configure script overwrites "LD".)
>
> Can you try installing a different "ld64" package, installing a
> different variant, or uninstalling it?
>
> -erik
>
> On Thu, Nov 16, 2023 at 5:29 PM Bernard Kelly <physicsbeany at gmail.com>
> wrote:
> >
> > Thanks, Erik.
> >
> > Hmm, OK. It turns out that I *have* ld64 installed via MacPorts, and I
> think that's what's being used here:
> >
> > gs66-shannon:~ bjkelly1$ L /opt/local/bin/ld*
> > lrwxr-xr-x 1 root admin 8 Sep 28 19:42 /opt/local/bin/ld -> ld-xcode
> > lrwxr-xr-x 1 root admin 16 Sep 28 19:42 /opt/local/bin/ld-classic ->
> ld-classic-xcode
> > lrwxr-xr-x 1 root admin 32 Sep 28 19:41
> /opt/local/bin/ld-classic-xcode -> ../libexec/ld64/ld-classic-xcode
> > lrwxr-xr-x 1 root admin 24 Sep 28 19:41 /opt/local/bin/ld-xcode ->
> ../libexec/ld64/ld-xcode
> > -rwxr-xr-x 1 root admin 176 Sep 28 20:06 /opt/local/bin/ld.lld-mp-14
> > -rwxr-xr-x 1 root admin 180 Sep 28 20:06 /opt/local/bin/ld64.lld-mp-14
> >
> > I just tried setting LD = /opt/local/bin/ld-classic , but the failure is
> the same.
> >
> > I then tried using the pre-MacPorts system linker, LD = /usr/bin/ld, but
> the failure is unchanged.
> >
> > Perhaps there's a linker flag I should be setting? Right now I have
> nothing in LDFLAGS.
> >
> > Bernard
> >
> > On Thu, Nov 16, 2023 at 4:41 PM Erik Schnetter <schnetter at gmail.com>
> wrote:
> >>
> >> Bernard
> >>
> >> Your C++ compiler is probably fine, but your linker ("ld") is not, it
> >> cannot handle GCC's output.
> >>
> >> I have a MacPorts package "ld64" installed. Maybe that would help?
> >>
> >> -erik
> >>
> >> On Thu, Nov 16, 2023 at 3:49 PM Bernard Kelly <physicsbeany at gmail.com>
> wrote:
> >> >
> >> > Hi Roland.
> >> >
> >> > I'm attaching the config.log file here (I had to hunt it down in
> configs/sim/config-data, since the configure step failed before it could
> point to anything).
> >> >
> >> > Since the logfile gives a small C++ program that failed to compile, I
> copied it to testGPP2.cpp, and tried compiling it myself; and yes, it
> failed. Errors from this are short enough to quote here:
> >> >
> >> > ------------
> >> > gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13
> testGPP2.cpp
> >> > ld: warning: ignoring duplicate libraries: '-lgcc'
> >> > 0 0x1049cb648 __assert_rtn + 72
> >> > 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned
> long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204
> >> > 2 0x104915924
> ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const +
> 15164
> >> > 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile
> const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&)
> const + 420
> >> > 4 0x1a0274440 _dispatch_client_callout2 + 20
> >> > 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224
> >> > 6 0x1a028884c _dispatch_apply_with_attr_f + 1180
> >> > 7 0x1a0288a38 dispatch_apply + 96
> >> > 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292
> >> > 9 0x10493e170 main + 9048
> >> > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function
> findAtom, file Relocations.cpp, line 1336.
> >> > collect2: error: ld returned 1 exit status
> >> > ------------
> >> >
> >> > As for your other question, no, there's no environment variable set
> with a name containing CXX.
> >> >
> >> > Thanks, Bernard
> >> >
> >> >
> >> > On Thu, Nov 16, 2023 at 3:35 PM Roland Haas <rhaas at illinois.edu>
> wrote:
> >> >>
> >> >> Hello Bernard,
> >> >>
> >> >> Odd. You have the correct CXXFLAGS and the compiler seems new enough.
> >> >>
> >> >> Could you attach the config.log file that the run produced (should be
> >> >> mentioned near the end with full path).
> >> >>
> >> >> Since this has been an issue in the past: there are no environment
> >> >> variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds
> >> >> nothing)?
> >> >>
> >> >> Yours,
> >> >> Roland
> >> >>
> >> >> > Hi. I tried making a new configuration on my Macbook (MacOS
> Ventura,
> >> >> > 13.6.2) after a gap of several months, and it's now failing the
> "make
> >> >> > sim-config" step with a complaint about the C++ compiler not being
> >> >> > C++11-compliant -- end of the make config step screen output is
> below.
> >> >> >
> >> >> > I'm using the latest available Macports-supplied GNU compilers
> >> >> > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options:
> >> >> >
> >> >> > ---------- compiler flags -----------
> >> >> > CPP = /opt/local/bin/cpp-mp-13
> >> >> > CC = /opt/local/bin/gcc-mp-13
> >> >> > CXX = /opt/local/bin/g++-mp-13
> >> >> > CPPFLAGS =
> >> >> > CFLAGS = -std=c99
> >> >> > CXXFLAGS = -std=c++14
> >> >> > C_LINE_DIRECTIVES = yes
> >> >> > OPTIMISE = yes
> >> >> > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG
> >> >> > C_OPTIMISE_FLAGS = -O2 -march=native
> >> >> > CXX_OPTIMISE_FLAGS = -O2 -march=native
> >> >> > OPENMP = yes
> >> >> > CPP_OPENMP_FLAGS = -fopenmp
> >> >> > C_OPENMP_FLAGS = -fopenmp
> >> >> > CXX_OPENMP_FLAGS = -fopenmp
> >> >> > WARN = yes
> >> >> > CPP_WARN_FLAGS = -Wall
> >> >> > C_WARN_FLAGS = -Wall
> >> >> > CXX_WARN_FLAGS = -Wall
> >> >> > ---------- end of compiler flags -----------
> >> >> >
> >> >> > Can anyone suggest what's up? The error says that the C++ compiler
> is
> >> >> > failing to do range-based for statements, but I can compile & run
> a simple
> >> >> > program with a range-based for statement, so this seems unlikely.
> >> >> >
> >> >> > I'm currently on ET_2023-05, but have this problem with ET_2022_11
> as well,
> >> >> > and with gcc-mp-12.
> >> >> >
> >> >> > Thanks, Bernard
> >> >> >
> >> >> > --------------- last bit of screen output ---------
> >> >> > checking if compiler has broken omp collapse... no
> >> >> > checking for getopt_long_only... yes
> >> >> > checking for working const... yes
> >> >> > checking for C inline... inline
> >> >> > checking for C static inline... static inline
> >> >> > checking for C restrict... restrict
> >> >> > checking for C++ restrict... __restrict__
> >> >> > checking for C++ copysign... std::copysign
> >> >> > checking for C++ fpclassify... std::fpclassify
> >> >> > checking for C++ isfinite... std::isfinite
> >> >> > checking for C++ isinf... std::isinf
> >> >> > checking for C++ isnan... std::isnan
> >> >> > checking for C++ isnormal... std::isnormal
> >> >> > checking for C++ signbit... std::signbit
> >> >> > checking for C _Pragma... yes
> >> >> > checking for C function __attribute__((__const__))... yes
> >> >> > checking for C++ function __attribute__((__const__))... yes
> >> >> > checking for C++ member function __attribute__((__const__))... yes
> >> >> > checking for C function __attribute__((__pure__))... yes
> >> >> > checking for C++ function __attribute__((__pure__))... yes
> >> >> > checking for C++ member function __attribute__((__pure__))... yes
> >> >> > checking for C data __attribute__((__common__))... yes
> >> >> > checking for C+ data __attribute__((__common__))... yes
> >> >> > checking for C function __attribute__((__noinline__))... yes
> >> >> > checking for C++ function __attribute__((__noinline__))... yes
> >> >> > checking for C++ member function __attribute__((__noinline__))...
> yes
> >> >> > checking for C function __attribute__((__always_inline__))... yes
> >> >> > checking for C++ function __attribute__((__always_inline__))... yes
> >> >> > checking for C++ member function
> __attribute__((__always_inline__))... yes
> >> >> > checking for C __attribute__((__unused__))... yes
> >> >> > checking for C++ __attribute__((__unused__))... yes
> >> >> > checking for C __attribute__((__aligned__(...)))... yes
> >> >> > checking for C++ __attribute__((__aligned__(...)))... yes
> >> >> > checking for C __attribute__((__cold__))... yes
> >> >> > checking for C++ __attribute__((__cold__))... yes
> >> >> > checking for C __attribute__((__hot__))... yes
> >> >> > checking for C++ __attribute__((__hot__))... yes
> >> >> > checking for C __attribute__((__format__(printf, 1, 2)))... yes
> >> >> > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes
> >> >> > checking for C __attribute__((__noreturn__))... yes
> >> >> > checking for C++ __attribute__((__noreturn__))... yes
> >> >> > checking for C __attribute__((__nonnull__))... yes
> >> >> > checking for C++ __attribute__((__nonnull__))... yes
> >> >> > checking for C __attribute__((__returns_nonnull__))... yes
> >> >> > checking for C++ __attribute__((__returns_nonnull__))... yes
> >> >> > checking for C __builtin_expect... yes
> >> >> > checking for C++ __builtin_expect... yes
> >> >> > checking for C __builtin_trap... yes
> >> >> > checking for C++ __builtin_trap... yes
> >> >> > checking for C __builtin_unreachable... no
> >> >> > checking for C++ __builtin_unreachable... no
> >> >> > checking for C __builtin_assume_aligned... yes
> >> >> > checking for C++ __builtin_assume_aligned... yes
> >> >> > checking for C++ static_assert... yes
> >> >> > checking for C++ auto specifier... yes
> >> >> > checking for C++ lambda expressions... yes
> >> >> > checking for C++ range-based for statements... no
> >> >> > Cactus requires a C++11 compiler -- check your C++ compiler and C++
> >> >> > compiler flags
> >> >> >
> >> >> > Error reconfiguring sim-config
> >> >> > make: *** [sim-config] Error 2
> >> >> >
> >> >>
> >> >>
> >> >> Yours,
> >> >> Roland
> >> >>
> >> >> --
> >> >> My email is as private as my paper mail. I therefore support
> encrypting
> >> >> and signing email messages. Get my PGP key from http://pgp.mit.edu .
> >> >
> >> >
> >> >
> >> > --
> >> > ------------------------------------------------------------------
> >> > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC
> >> > Gravitational Astrophysics Laboratory --- Code 663
> >> >
> >> > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226
> >> > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly
> >> > ORCID: orcid.org/0000-0002-3326-4454
> >> > ------------------------------------------------------------------
> >> > _______________________________________________
> >> > Users mailing list
> >> > Users at einsteintoolkit.org
> >> > http://lists.einsteintoolkit.org/mailman/listinfo/users
> >>
> >>
> >>
> >> --
> >> Erik Schnetter <schnetter at gmail.com>
> >> http://www.perimeterinstitute.ca/personal/eschnetter/
> >
> >
> >
> > --
> > ------------------------------------------------------------------
> > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC
> > Gravitational Astrophysics Laboratory --- Code 663
> >
> > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226
> > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly
> > ORCID: orcid.org/0000-0002-3326-4454
> > ------------------------------------------------------------------
>
>
>
> --
> Erik Schnetter <schnetter at gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
--
------------------------------------------------------------------
Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC
Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226
Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly
ORCID: orcid.org/0000-0002-3326-4454
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20231121/2c959841/attachment-0001.htm>
More information about the Users
mailing list