Linking libMacportsLegacySupport privately?

[Chris Jones]

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

> 
> Fred Wright