On Thu, 27 Mar 2025, Chris Jones via macports-dev wrote:
On 27/03/2025 12:35 pm, René J.V. Bertin wrote:
Hi,
I've been experimenting with libc++ 17 which is a prerequisite to using
GCC13+ with libc++ instead of libstdc++ .
I kept the static legacy-support library linking (may have had to, can't
remember that) and just now realise that all the functions from that
archive (or at least the from the modules that get pulled in) are exported
by libc++ .
That's probably a bad idea. ISTR a post from Ken regarding compiler uses
of legacy-support being statically linked, but that was to avoid circular
dependencies. There may have been some circular dependency issues at one
time, due to legacy-support's being constrained to MacPorts compilers in
some cases by the cxx_stdlib setting, but I fixed that over a year ago.
Nowadays, legacy-support is completely dependency-free except for needing
apple-gcc42 to build on 10.4, and static linking should be avoided as much
as possible.
which libc++ in particular are you talking about here ? For sure the system
libc++ will never export anything from legacysupport.
I presume that "libc++ instead of libstdc++" means that it's not referring
to a system libc++.
The libc++ versions as provided by the MacPorts clang ports might well
include some symbols from legacysupport, as its use is required to build
these compilers on old systems. I don't thunk hiding these symbols in
these versions is at all a good idea.
A proper compiler should make a proper distinction between host
requirements and target requirements, though I wouldn't put it past GCC to
get that wrong. What the compiler needs to build and run should be
completely independent from what its target needs.
If libc++ is statically linked with legacy-support, then it will of course
contain any legacy-support symbols that it references. If it's
dynamically linked, then it won't unless it's been explicitly configured
to do so.
Fred Wright
