On Fri, 28 Mar 2025, Chris Jones via macports-dev wrote:
On 27/03/2025 10:08 pm, Fred Wright wrote:
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.
They intentionally link statically.
https://github.com/macports/macports-ports/blob/master/lang/llvm-20/Portfile#L15
For what's almost certainly an obsolete reason. Can you provide any
justification beyond "it used to be necessary" or "that's the way it's
always been done, for reasons nobody remembers"?
A proper Portfile comment doesn't merely explain *what* it's doing, but
also *why* it's doing it (if it isn't obvious). The comment in that case
is clearly deficient.
Fred Wright