Linking libMacportsLegacySupport privately?

[Fred Wright]

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