[MacPorts] #55604: source-highlight: boost - symbol(s) not found for architecture x86_64

[MacPorts]

#55604: source-highlight: boost - symbol(s) not found for architecture x86_64
-------------------------------+-------------------
  Reporter:  adfernandes       |      Owner:
      Type:  defect            |     Status:  new
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:  2.4.2
Resolution:                    |   Keywords:
      Port:  source-highlight  |
-------------------------------+-------------------

Comment (by ryandesign):

 Replying to [comment:3 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.

--
Ticket URL: <https://trac.macports.org/ticket/55604#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS