[MacPorts] #56013: source-highlight @3.1.8_3: crashes (and fails to build) on 10.6

[MacPorts]

#56013: source-highlight @3.1.8_3: crashes (and fails to build) on 10.6
-------------------------------+--------------------------------------
  Reporter:  Ionic             |      Owner:  Mihai Moldovan <ionic@…>
      Type:  defect            |     Status:  closed
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:  fixed             |   Keywords:
      Port:  source-highlight  |
-------------------------------+--------------------------------------

Comment (by Ionic):

 Replying to [comment:7 ryandesign]:
 > Replying to [comment:2 Ionic]:
 > > Recompiling with `cxx11 1.1` and adding `-stdlib=c++11` causes other
 corruption:
 >
 > `-stdlib=c++11` is not a valid flag. Perhaps you meant `-std=c++11`
 and/or `-stdlib=libc++`.

 Sorry, of course I meant `stdlib=libc++`.

 [[br]]
 > Replying to [comment:3 Ionic]:
 > > Switching to a `libc++`-based installation as described in
 [[LibcxxOnOlderSystems]] fixes this bug, which is not very surprising.
 >
 > That does surprise me. That should not have worked, since that works by
 passing the `-stdlib=libc++` flag every time C++ files are compiled or
 linked. Since that flag was missing when linking, linking should have
 failed. And it should have succeeded when ''not'' using
 LibcxxOnOlderSystems.

 As far as I've seen, source-highlight's dylib was linked against the
 system `libstdc++`. That's also visible in the crash report. I think the
 problem here is that the binary and library are built and linked against a
 different stdlib instead of the one found in library dependents (like the
 boost-regex library). Since two different C++ standard libraries are
 linked in this case, a lot of stuff breaks. If we build programs like
 `source-highlight` in C++11 mode and against the same stdlib as boost,
 such mismatched should not happen.

 [[br]]
 > > Given that boost seems to be linking against the system `libstdc++`,
 which doesn't support C++11, we could potentially fix this issue by having
 boost link against `macports-libstdc++`, which does support C++11, if the
 `libc++` is set to `libstdc++`. Comments?
 >
 > Since #55926 was fixed, on older systems, boost does ''not'' use the
 system libstdc++, which doesn't support C++11. It uses the MacPorts
 libstdc++, which does support C++11.

 That's correct, not sure where I got that idea from. It was linking
 against a libstdc++ version, but it was not the system one, but (the
 correct) MacPorts version.

 [[br]]
 > Replying to [comment:4 kencu]:
 > > Perhaps this is a `wontfix`?
 >
 > No, we should fix such problems by passing the `-stdlib=` flag where
 needed. This will continue to be necessary after we make libc++ the
 default cxx_stdlib, unless we change the clang compiler's default stdlib.
 I know you've advocated for that elsewhere so we don't need to discuss it
 again in this ticket.

 If doing the migration correctly by changing `cxx_stdlib` and forcing all
 usage of C++ code to be linked against this, such problems shouldn't come
 up any longer (unless we start mixing up `libc++` and `libstdc++`, but I
 hope there's no reason for this to happen).

 [[br]]
 > Using the cxx11 1.1 portgroup should not be necessary. The whole point
 of #55926 was to make C++11 features ''available'' to ports that use
 boost, but not to ''require'' ports that use boost to use C++11. If that
 didn't work for source-highlight -- if source-highlight doesn't build on
 older systems anymore unless C++11 is used now -- then we might need to
 reevaluate what we did in the boost port for #55926.

 It definitely didn't work. `source-highlight` was both linking against the
 system `libstdc++` and pulling in `libboost-regex-mt.dylib`, which linked
 against a different C++ stdlib. That lead to everything crashing. Only
 force-enabling C++11 mode and changing the stdlib at compile/link time
 directly to the one `boost` was built against fixed this issue.

 I do not see a way to fix such library mix up issues just by having boost
 build against a different stdlib. Other programs will always be linked
 against the default stdlib (if not specified otherwise) by the compiler.
 The only way this could *possibly* work is by using `-nostdlib` which
 avoids pulling in an stdlib - and hope that library dependencies will pull
 in a suitable stdlib. I don't know if programs and libraries will
 successfully link at build time with `-nostdlib`, though.

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