seems to be a tonne of opportunity to smoke fink

[Ken Cunningham]

the libcxx port is used currently only 10.5 and 10.6 Intel systems. 

It gives them a system libcxx installed as /usr/lib/libc++.dylib and /usr/lib/libc++abi.dylib that is quite a bit newer than what is installed on 10.7, 10.8, 10.9, or 10.10. I forget about where it comes in -- 10.13 is my best guess.

For any of those systems where libc++ is too old, we use macports-libcxx. It has some warts -- certain things break when using macports-libcxx. But most things work.

Changing the libcxx port to use the libc++ from clang-11/llvm-11 will make it newer, of course, affecting only 10.5 and 10.6 Intel. This will come at the cost of a more complicated bootstrap procedure and quite possibly some incompatible software might be found.

So -- personally I  would leave libcxx alone, probably forever, and let it be as is. 

But there is a discussion to be had about the ups and downs of making that a newer libc++ for 10.5. and 10.6, sure... 

because of the way things work, anything that needs a newer libc++ than what is on 10.7 will still need to force macports-libcxx anyway on 10.5 and 10.6, so ... questionably beneficial.

K




> On Sep 28, 2024, at 6:49 PM, Gagan Sidhu via macports-dev <macports-dev at lists.macports.org> wrote:
> 
> i just wanted to follow up on this a little.
> 
> i noticed that *macports-libcxx* is the ‘good one’ and libcxx is the ‘old one’.
> 
> macports-libcxx+universal takes quite a while to install since it builds llvm-11 from scratch, but i suspect it’s worth it.
> 
> i think a discussion needs to happen to rename ken’s port to libcxx, and the latter to something that conveys since macports users should be pointed to his port before the existing one.
> 
> i really think macports-libcxx should replace libcxx. i noticed ken has added himself to the open tickets on libcxx and also christopher chavez has asked questions about its usefulness.
> 
> put briefly: i found libcxx to be unhelpful when (successfully) building nodejs14/18, opting to link in llvm’s libcxx from /opt/libexec
> 
> flat out, libcxx is ’too old’ to deserve retention of the primary name for a crucial library on macports. 
> 	-i noticed that ken removed himself from maintaining libcxx since it’s for snow leopard and older. 
> 		https://github.com/macports/macports-ports/commit/8ce65b33a1970046bdcb22ee86227301427d6135
> 
> i therefore think this should be on “the council”’s next meeting minutes.
> 	-thanks for all your hard work btw ken. i have to buy a beater sata ssd to start testing portfile edits with your macports-libcxx.
> 		-it is a travesty this hasn’t been massaged into the entire list of ports. 
> 
> to have nodejs14/18/gdb/etc all on an “old” 10.7 install really speaks to ethos of this package manager and, at one time, this operating system.
> 
> nice job man.
> 
> Thanks,
> Gagan
> 
>> On Sep 25, 2024, at 2:14 PM, Gagan Sidhu via macports-dev <macports-dev at lists.macports.org> wrote:
>> 
>> thanks ken. i am aware of this library, but i’ve never used it outside of building clang with the +libstdcxx flag.
>> 
>> i guess this may be a case of updating some portfiles to use this flag.
>> 
>> doesn't nodejs18 have this portgroup enabled? i see
>> 
>>> PortGroup               legacysupport 1.1
>> 
>> 
>> and 
>> 
>>> [legacysupport::get_library_link_flags]
>> 
>> 
>> in the LDFLAGS. 
>> 
>> i assumed that meant it was included. or must 
>> 
>>> legacysupport.use_mp_libcxx yes
>> 
>> 
>> still be added? 
>> 
>> Thanks,
>> Gagan
>> 
>>> On Sep 25, 2024, at 2:05 PM, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
>>> 
>>> check out:
>>> 
>>> https://ports.macports.org/port/macports-libcxx/
>>> 
>>> 
>>>> On Sep 25, 2024, at 12:22 PM, Gagan Sidhu via macports-dev <macports-dev at lists.macports.org> wrote:
>>>> 
>>>> … but i guess we’re shorthanded.
>>>> 
>>>> today i built nodejs18 with a couple of flags anyone could find if they attempted it (after removing the OS check via sudo port edit), and then hard-coding (lol it was a test) -L/opt/local/libexec/llvm-17/lib/libc++
>>>> 
>>>> it works completely fine if i put that path on LD_LIBRARY_PATH (“just?” lol)
>>>> - i know that’s a huge siren for the maintainers here lol, i get it, but the point isn’t that this version was ready for distribution)
>>>> 
>>>> given the static libc++ included in the ports llvm, it seems to me there is a tonne of opportunity to use the static libc++ from newer llvms to supplement the older /usr/lib/libc++ to take our game to the next level.
>>>> 
>>>> of course it may not be that simple. i’m far from a compiler expert, acknowledge the library name clash of /usr/lib/libc++ and the static in /opt/local/libexec/llvm-<version>, and this may be what the macports libc++ was designed to alleviate.
>>>> 
>>>> i just thought it was pretty interesting to have a newish node on an “old” OS with relatively little effort.
>>>> - i bet this experience would apply to a lot of ports, hence my first line (underhanded).
>>>> 
>>>> 
>>>> Thanks,
>>>> Gagan
>>>> 
>>> 
>> 
>