Closed yukio-takeuchi closed 4 years ago
Fixes ebc448df93ff8451729936079f53c024a1fba0de f0e24d1ddad7fbf6b25ec625e21d2a97948e6b1c 55c6405d2f9333b331904cba675ba80797dfa1ea
Apple has its own version of llvm clang for the MacOS. The version numbers are different for both. The apple clang version can be found from clang++ --version which will be used for libadmb filename.
For more information see
Currently, in src/GNUMakefile, if CXX is clang++ CXXVERSION is determined as
CXXVERSION is attached to file names of ADMB libraries on MacOS 10.15.3 if
make clang++-all
command is used, e.g.The number
4
is taken from the return value ofclang++ -dumpversion
On the other hand , as pointed by developers of llvm.org, until very recently the return value ofclang(++) -dumpversion
was hard coded to be 4.2.1 for ["for gcc compat"]https://github.com/llvm-mirror/clang/commit/95a907fc0f2f717dca38a379c1d2353bfea06d4f In the case of clang(++) on Ubuntu 18.04, only starting from clang 9.0.0,clang(++) -dumpversion
command produces consistent value to actual version number.Is it possible to set CXXVERSION differently? E.g.
This used a predefined MACRO __clang_major__ to retrieve "major" version number of clang(++) .
This may also allow resolve inconsistency on MacOS (10.15 )between the case when
make (c++-)all
command is used and the case whenmake clang++-all
command is used.In the case of former command, file names of ADMB libraries become e.g. libadmb-x86_64-macos-clang++11.a If latter command is used, they will be e.g. libadmb-x86_64-macos-clang++4.a
However, since
cc
andc++
command on MacOS is a wrapper command ofclang
andclang++
respectively. If alternative command mentioned above to determine CXXVERSION is used, this inconsistency on MacOS can be resolved.