source-highlight: boost - symbol(s) not found for architecture x86_64

[adfernandes (Andrew Fernandes)]

Installing source-highlight @3.1.8_2 fails with

:info:build /bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++  -pipe -Os -stdlib=libc++ -arch x86_64 -L/opt/local/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o check-regexp check-regexp_cmd.o check-regexp.o -lboost_regex-mt ../gl/libgnu.la 
:info:build libtool: link: /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 -o check-regexp check-regexp_cmd.o check-regexp.o  -L/opt/local/lib -lboost_regex-mt ../gl/.libs/libgnu.a
:info:build Undefined symbols for architecture x86_64:
:info:build   "boost::re_detail_106501::cpp_regex_traits_implementation<char>::transform_primary(char const*, char const*) const", referenced from:
:info:build       boost::cpp_regex_traits<char>::transform_primary(char const*, char const*) const in check-regexp.o
:info:build   "boost::re_detail_106501::cpp_regex_traits_implementation<char>::transform(char const*, char const*) const", referenced from:
:info:build       boost::cpp_regex_traits<char>::transform(char const*, char const*) const in check-regexp.o
:info:build ld: symbol(s) not found for architecture x86_64

But boost @1.65.1_1+gcc6+no_single+no_static+python36 is installed and active.

The main.log (attached) indicates that it should be the one that is used.

[mf2k (Frank Schima)]

I have found that boost +gccX causes problems with many ports. My workaround is to install it without gcc.

$ port installed boost
The following ports are currently installed:
  boost @1.65.1_1+no_single+no_static+python36 (active)

I believe this is really a boost bug.

[ryandesign (Ryan Carsten Schmidt)]

If it were up to me, the gcc variants would be removed from the boost port, since they cause these problems.

Looks like based on a patch proposed by Michael in #50671, I re-added the gcc variants after having previously removed them. So Michael, can I remove them again?

[michaelld (Michael Dickens)]

Hmmm ... well this issue to me highlights (or at least I think it does) that there needs to be a better way to set the default c++ stdlib for port building compatibility. Some ports build nicely with G++ / libstdc++, while others do with Clang++ / libc++, while most can build using either. Generally once the correct c++ stdlib is set the project will build & execute correctly, and it is possible to mix & match the c++ stdlib for different ports so long as there are no conflicts.

For this specific ticket, going back to my experience with building GNU Radio, it seems likely that there is some other boost and/or source-highlight dependency that isn't playing nicely with Boost / source-highlight / G++ here. For GR, I had to rebuild something like 5 dependencies to use the correct c++ stdlib before GR would both build and execute. It was quite the effort, IIRC. Boost was one of them, and required g++ hence why I added those variants back into the mix. Once I had all of the c++ stdlib settings correct, GR worked nicely on the target system (IIRC 10.6 not using the various hacks that are now in place).

All of the above said: @ryandesign if you wish to remove the gcc variants, go ahead and do so. I can always force port to use a specific compiler / c++ stdlib. I also might be entirely incorrect in my assessment above; these things can be pretty complicated!

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld:

Some ports build nicely with G++ / libstdc++, while others do with Clang++ / libc++, while most can build using either. Generally once the correct c++ stdlib is set the project will build & execute correctly, and it is possible to mix & match the c++ stdlib for different ports so long as there are no conflicts.

It has been our experience that it is not generally possible to mix and match the C++ stdlib, because a program or library built with one C++ stdlib might try to exchange C++ objects with a program or library built with a different C++ stdlib, and that's not possible and will result in build failures (if the two C++ stdlibs are libstdc++ and libc++) or runtime crashes (if the two C++ stdlibs are two different versions of libstdc++). For this reason, we don't in MacPorts try to do that. We require the user to specify a single global C++ stdlib that all ports will use. Following the defaults that Apple has provided in macOS, users of 10.9 and later use libc++, and users of 10.8 and earlier use libstdc++ (unless they use LibcxxOnOlderSystems).

Apple's gcc 4.2.1-era libstdc++ included with the system does not support C++11 or newer, so for ports that require C++11 or newer, the cxx11 1.1 portgroup offers an alternative for 10.8 and earlier where the compiler is instructed to use a newer libstdc++ from the libgcc port, in a compatibility mode that is supposed to play nice with Apple's older libstdc++, so that exchange of objects is possible. This is nicer for the user because unlike LibcxxOnOlderSystems it does not require the user to uninstall and reinstall all ports from source.

There are some exceptions to the prohibition on changing the C++ stdlib on a port by port basis. For example mongodb and cmake require C++11, but don't use any other C++ libraries, and don't provide any C++ libraries, so they stand alone and it's ok for them to force the use of libc++ even on systems that use libstdc++ for other ports.

For this specific ticket, going back to my experience with building GNU Radio, it seems likely that there is some other boost and/or source-highlight dependency that isn't playing nicely with Boost / source-highlight / G++ here. For GR, I had to rebuild something like 5 dependencies to use the correct c++ stdlib before GR would both build and execute. It was quite the effort, IIRC. Boost was one of them, and required g++ hence why I added those variants back into the mix. Once I had all of the c++ stdlib settings correct, GR worked nicely on the target system (IIRC 10.6 not using the various hacks that are now in place).

Looks like the gnuradio port already uses the cxx11 1.1 portgroup, so presumably everything should be working fine there without any of its dependencies needing to do anything special.

[ryandesign (Ryan Carsten Schmidt)]

In f9209f70be0e75925582f325797e35350e9f421a/macports-ports:

boost: Remove gcc variants again once and for all

Revbump to ensure nobody is using them.

gcc variants cannot be offered by boost because that would cause it to
use the gcc C++ standard library (libstdc++), which will cause build
failures for other ports that use boost and use the normal OS C++
standard library (libc++).

Closes: #55604