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