boost176 @1.76.0_10 broken after rev-update for new version of icu (on older macOS?)

[snowflake (Dave Evans)]

Lots of ports have received a rev-update after the new version of icu. Most seem to be building OK, but boost176 has some errors, at least on my macOS 10.11.6

Here's one error

...failed darwin.compile.c++ bin.v2/libs/log/build/darwin-16.0.6/release/threadapi-pthread/threading-multi/visibility-hidden/core.o...
darwin.compile.c++ bin.v2/libs/log/build/darwin-16.0.6/release/threadapi-pthread/threading-multi/visibility-hidden/severity_level.o
    "/opt/local/bin/clang++-mp-16"  -ftemplate-depth-1024 -fvisibility-inlines-hidden -Os -std=gnu++11 -stdlib=libc++ -arch x86_64 -stdlib=libc++ -fPIC -m64 -O3 -Wall -fvisibility=hidden -dynamic -gdwarf-2 -fexceptions -Wno-inline  -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3 -DBOOST_LOG_WITHOUT_DEBUG_OUTPUT -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -D__STDC_CONSTANT_MACROS  -I"." -I"/opt/local/include" -I"libs/log/src"  -c -o "bin.v2/libs/log/build/darwin-16.0.6/release/threadapi-pthread/threading-multi/visibility-hidden/severity_level.o" "libs/log/src/severity_level.cpp"
In file included from libs/log/src/severity_level.cpp:18:
In file included from ./boost/log/sources/severity_feature.hpp:31:
In file included from ./boost/log/utility/strictest_lock.hpp:19:
In file included from ./boost/mpl/integral_c.hpp:32:
./boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
    typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
                              ^
./boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                              ^
1 error generated.

[kencu (Ken)]

might be because it’s rebuilding now with the stricter clang-16

if so, an older clang could be forced via blacklisting.

or better, newer boost versions have probably fixed whatever the issue is, and that fix might be backported

[snowflake (Dave Evans)]

Building with the clang15 variant works

sudo port -s upgrade --enforce-variants boost176 +no_single +no_static +python311 +clang15

[tehcog (tehcog)]

broken on mavericks, but builds with:

sudo port upgrade boost176 configure.compiler=macports-clang-15

[kencu (Ken)]

looks relevant:

​https://github.com/boostorg/mpl/issues/69

[kencu (Ken)]

someone thinks this is a fix for this, it seems:

​https://github.com/ecatmur/mpl/commit/8499ae7e4ff0cf798367ebe6ea9fb991aa43db6c

worth trying

[RobK88]

Same problem on Lion and Mtn Lion. But using clang-15 is the workaround.

sudo port upgrade boost176 configure.compiler=macports-clang-15

[erikbs]

Another workaround is to edit this line in Portfile:

configure.cxxflags-append -std=gnu++11

so that it reads

configure.cxxflags-append -std=gnu++11 -Wno-enum-constexpr-conversion

The constexpr enum warning is now a hard error, but according to the build logs, it was only a soft warning in the LLVM/Clang version on which the latest Xcode/AppleClang version is based on (a 16.0.0 pre-release maybe?). It was made a hard error because doing this is undefined behaviour. Disabling the warning is therefore bad, but is no worse than using a compiler version that does not have this check at all (Clang 15). I suggest suppressing the warning/error instead of blacklisting Clang 16.

[kencu (Ken)]

If the fix in ​https://trac.macports.org/ticket/68920#comment:7 works that would be desirable...

We could supress the warning if -Wno-enum-constexpr-conversion accepted by the compilers macports supports that could be used here.

[erikbs]

Replying to kencu:

If the fix in ​https://trac.macports.org/ticket/68920#comment:7 works that would be desirable...

We could supress the warning if -Wno-enum-constexpr-conversion accepted by the compilers macports supports that could be used here.

I agree. I forgot to take into consideration that adding this flag only for some compilers / compiler versions adds complexity to the Portfile. I will try the fix you mentioned on 10.9 once my battery has charged a bit more and report back.

[erikbs]

It was C++17 that introduced the requirement that no constexpr enum be set to a value outside its range, but Clang seems to enable this check regardless of C++ standard. The patch thus had no effect in itself. However, it works perfectly if I up the C++ standard from 2011 to 2017, but that raises another question: do we want that? I see that the Portfile sets compiler.cxx_standard twice, both times to 2011 (in addition, a compiler flag for using the GNU dialect is set once). There is a comment explaining that Boost does not have such a requirement, but that requiring C++11 in MacPorts allows us to build Boost successfully on more platforms.

These are the changes I did to implement the suggestion in comment 7:

devel/boost176/Portfile

@@ -38 +38 @@
 distname        boost_${distver}
 use_bzip2       yes
 
-compiler.cxx_standard     2011
+compiler.cxx_standard     2017
 compiler.blacklist-append {clang < 1000}
 
 depends_lib-append \
@@ -144 +144 @@
 # Further: Building Boost using C++11 compliance does not seem to then
 # require ports depending on Boost to also require C++11 compliance,
 # and requiring it does make such building easier for those ports.
-configure.cxxflags-append -std=gnu++11
-compiler.cxx_standard   2011
+configure.cxxflags-append -std=gnu++17
+compiler.cxx_standard   2017
 
 # This flag fixes the return type of unsetenv(3)
 # See: https://trac.macports.org/ticket/63121

devel/boost176/files/patch-boost-clang16-cpp17-compat.diff

@@ -83 +83 @@
 
    // Metafunction:
    //
+--- boost/mpl/aux_/integral_wrapper.hpp.orig
++++ boost/mpl/aux_/integral_wrapper.hpp
+@@ -56,7 +56,8 @@ struct AUX_WRAPPER_NAME
+ // have to #ifdef here: some compilers don't like the 'N + 1' form (MSVC),
+ // while some other don't like 'value + 1' (Borland), and some don't like
+ // either
+-#if BOOST_WORKAROUND(__EDG_VERSION__, <= 243)
++#if BOOST_WORKAROUND(__EDG_VERSION__, <= 243) \
++    || __cplusplus >= 201703L
+  private:
+     BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, next_value = BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (N + 1)));
+     BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, prior_value = BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (N - 1)));

(The patch hunk I added is missing timestamps for the files, I copied in the diff from GitHub and added the file name lines instead of running diff -u locally. It works anyway.)

What I do not like about the above solution is that it would require introducing a C++ standard requirement that is much higher than Boost actually needs. One option is enabling C++17 only for compilers that support it (Clang 5 and later) or for compilers affected by the constexpr enum thing (Clang 16 and later), but at the cost of extra complexity in the Portfile. Another solution is to patch in a check for __clang_major__ >= 16 instead of __cplusplus >= 201703L. That would eliminate the need for raising the C++ standard requirement (and even changing the Portfile at all). It is also clean and safe, so in my opinion this is actually the best solution. It reduces the diff to:

devel/boost176/files/patch-boost-clang16-cpp17-compat.diff

@@ -83 +83 @@
 
    // Metafunction:
    //
+--- boost/mpl/aux_/integral_wrapper.hpp.orig
++++ boost/mpl/aux_/integral_wrapper.hpp
+@@ -56,7 +56,8 @@ struct AUX_WRAPPER_NAME
+ // have to #ifdef here: some compilers don't like the 'N + 1' form (MSVC),
+ // while some other don't like 'value + 1' (Borland), and some don't like
+ // either
+-#if BOOST_WORKAROUND(__EDG_VERSION__, <= 243)
++#if BOOST_WORKAROUND(__EDG_VERSION__, <= 243) \
++    || __clang_major__ >= 16
+  private:
+     BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, next_value = BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (N + 1)));
+     BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, prior_value = BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (N - 1)));

I verified that it works on my system, so I created a pull request: ​https://github.com/macports/macports-ports/pull/21839

[erikbs]

In f68cfe6a30d193121170cdf842eda5d70d079a40/macports-ports (master):

boost176: fix compilation with Clang >= 16 (​https://github.com/macports/macports-ports/pull/21839)

Fixes: #68920