Re: Linking libMacportsLegacySupport privately?

[Chris Jones via macports-dev]

> On 28 Mar 2025, at 6:01 pm, Fred Wright <f...@fwright.net> wrote:
> 
> 
>> 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"?

Not at all. LLVM primarily provides static libraries, and in order to get these 
to use legacy support features where required they need to be linked statically 
as well. 
> 
> 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.

Here I agree, the comment could explain that rationale better.

 Chris

> 
> Fred Wright