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@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.web...@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@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
>>> 
>> 
> 

Reply via email to