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

MacPorts noreply at macports.org
Mon Mar 19 00:57:46 UTC 2018

#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
 > `-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++`.

 > 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

 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.

 > > 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.

 > 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).

 > 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

More information about the macports-tickets mailing list