Linking libMacportsLegacySupport privately?

[Fred Wright]

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