[MacPorts] #56013: source-highlight @3.1.8_3: crashes (and fails to build) on 10.6
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`
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>
Ports system for macOS
More information about the macports-tickets