Re: seems to be a tonne of opportunity to smoke fink

[Gagan Sidhu via macports-dev]

> On Sep 28, 2024, at 9:29 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> 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.
gotcha
>  
> 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.
i saw that ticket by barracuda or whatever name he chooses to use (lol), the 
ticket with the -nostdinc.

i experienced similar wonkiness when trying to using the 
legacysupport.use_mp_libcxx yes flag.

however i have yet to encounter a case of failure yet when i manually add 
-L/opt/local/lib/libc++ to the LDFLAGS and build, assuming the issue was 
related to an older libc++

> 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. 
> 
i understand what you’re saying so i guess that’s fine. i thought it was for 
powerpc machines, but if it’s for early intel machines then the nomenclature 
makes more sense.
> 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... 
> 
in my opinion, and while it’s clear the lack of weak references and thread 
local storage in 10.6 is a disadvantage, they aren’t things that are 
insurmountable.
        -the lack of libdispatch in 10.5, however, makes things challenging.

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

this is why i proposed the renaming. i did an otool -L on all of the stuff in 
/opt/local/libexec/clang-11 and none of it is tied to the libcxx, but then i 
saw they were static, so your commentary has illuminated the situation greatly.

we’re sitting on a gold mine and it’s like such a shock we’re letting those 
BREWsers (brew losers) just take our spot.

something must be done about this. they are losers. yes i did just “ad hominem” 
them (i bet they like richard dawkins too, like real losers do)

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