thanks for the thoughtful response. just before i follow-up, i wanted to make clear it wasn’t my intention to intertwine my position in libcxx with the specific ports i mentioned earlier.
also, whilst you have distinguished libcxx from macports-libcxx, i think the important thing is to understand how macports-libcxx is more important for 10.7+ systems > On Sep 29, 2024, at 8:47 AM, Ken Cunningham <[email protected]> > wrote: > > sure, there are many challenges building current software on older systems. > > regarding a newer lldb for older systems, I built one by hand too, but nobody > has so far done the work to fix it for the general case. For me, I often > debug usually on 10.14, where many tools do work, yet the fixes apply back to > older systems. If you wanted to take on the project of getting an lldb like > lldb-5.0 running on 10.6 and up, we’d all appreciate that. > > but altering the libcxx port would not be needed for that. it isn’t. i don’t know if it’s possible to get a newer lldb working on older macs. -in theory it is. i think maybe the problem with lldb-mp-5.0 is that it is trying to find or rely on an old python that is missing ’six’. -no matter what though, i’ve tried to install six via python26/python27{-apple} and it still didn’t seem to be happy. right now lldb-mp-5.0 uses libcxx which seemed fine, because i guess lldb-5.0 is older than the last update to libcxx. > > regarding glib2, yes it needs work for more arch support too. there is a > ticket for that. There is a maintainer who was, for a while, white-hot keen > and took over about 500 ports and then has basically disappeared the past > year or so. Sometime ports having maintainers is actually a bad thing, as > others tend to leave things to them. If you wanted to make an attempt to > upgrade glib2 that would be appreciated too. i was referencing gdb, not glib, but i know first-hand the challenges involved with building it since i cross build it for a router firmware i produce. > > but the libcxx port is not involved in that fix either. > it will be now for gdb, at least. the latest version has missing cxx symbols that are only resolved by macports-libcxx. -libcxx cannot satisfy these requiremetns. > regarding the nodejs ports, same thing. Have at it. They may or may not need > macports-libcxx on older systems, I haven’t looked that closely. > > but the libcxx port is not involved there either. currently there is no libcxx dependency for nodejs. it will probably be macports-libcxx, but again i just find the nomenclature a little unwieldy. > > > > I’m a “focus-and-simplify” guy. Spend time where it is most needed. Eliminate > cruft and screwy confusing spaghetti code, etc. > > Moving the ball forward on your noted port failures won’t be helped by > opening a Pandora’s box of upgrading the libcxx port on 10.6. i wasn’t saying upgrade the port of libcxx. i wast just thinking maybe the names for libcxx and macports-libcxx could be changed so that macports-libcxx becomes libcxx and then libcxx becomes libcxx-legacy to convey that it is the foundational libcxx for 10.5/10.6 systems, which then allows those systems to build macports-libcxx. i get that libcxx is a dependency for macports-libcxx on 10.5 and 10.6, but those systems are far smaller than the rest that require a newer libcxx (and presumably macports-libcxx) and thus i think the names should reflect their current popularity. > > Ken > >> On Sep 29, 2024, at 05:13, Gagan Sidhu via macports-dev >> <[email protected]> wrote: >> >> >> >>>> On Sep 28, 2024, at 11:14 PM, Ken Cunningham >>>> <[email protected]> wrote: >>>> >>>> >>>> >>>>> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev >>>>> <[email protected]> wrote: >>>> >>> >>>> in my opinion, and while it’s clear the lack of weak references and thread >>>> local storage in 10.6 is a disadvantage, >>> >>> weak references and thread_local (emulated_tls, just like gcc does) work >>> 100% just fine on 10.5 and 10.6, and have done so for years now >> i understand the macports compilers offer these featuers, but i was just >> referring to the operating system features. >> >>> >>> >>> >>> >>>> 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) >>> >>> >>> >>> >>> I don't know what you are referring to. >>> >>> You can build almost any software you want, right now, on 10.5 and 10.6 >>> using the current libcxx port on those systems, and the system lib++ on >>> 10.7 up. >> >> i think in this past week i’ve used ports more than i ever have in the past >> twenty years of installing it, and while your general statement is correct, >> i must provide some corrections to it below. >>> >>> >>> And for systems where the installed libc++ is too old (usually requiring >>> filesystem, which came in with 10.15) we boot them up to use >>> macports-libcxx quite successfully. >>> >>> >>> I appreciate your enthusiasm. I think you need to spend quite a bit more >>> time understanding how things work in MacPorts now, as what you are >>> proposing actually offers nothing we don't already have. >> >> with your macports-libcxx, i can’t disagree that macports has everything. >> but the question is: does it all work out of the box? the answer is ’no’. >> >> examples: >> >> 1. the latest gdb is ‘broken’ because it relies on sp_mut from a libc++ >> newer than what is on 10.7, and the build will fail ‘out of the box’. >> -gdb universal is ‘broken’ because there are more comments needed to the >> newer makefiles to ensure the libtool archive files do not clash when >> merging the destroots of i386 and x86_64 >> 2. as explained earlier this week, both nodejs14 and nodejs18 fail to build >> on 10.7 because no one has tried to build them on 10.7 and look at the >> issues. >> -the current portfiles simply stop anyone from trying to even install it >> on macs lower than 10.9 >> 3. lldb-mp-xx will fail pretty badly on (5.0 and up) 10.7, and i don’t think >> this is just a matter of a libcxx. it took a few involved edits. not saying >> they were super-hard, but they weren’t easy. >> >> in short, you are correct that users are able to build “any software you >> want”, but only with some involved _EDITS_ of the _CURRENT_ portfiles of >> the aforementioned ports. >> -this is challenging for people who may have experience in development, >> but none that are relevant to macports (though i’ve leeched for 20 years >> almost) for two reasons: >> 1. there is new syntax/nomenclature/familiarity required in modifying >> the portfiles themselves >> 2. there are changes required to the actual build (i.e. cflags/ldflags >> etc) that also need to be discovered by ‘playing’ with the build directory >> in /opt/local/var/macports/build/*software* >> -the knowledge in step 2 then needs to be summarised into step 1, which >> shows there are two layers of experience to contribute effectively to the >> macports system. >> >> it is a great front-end and i appreciate it very much, but i really ‘had to >> care’ before i learned about this two-stage process mentioned above. >> >> of course the next question would be: are we expecting the macports user to >> know how to do all of this? >> -i guess that goes to the ethos of the package manager maintainers. >> >> personally i think i’ve shown i haven’t suffered if that is your expectation. >> -BUT with some maintenance of existing portfiles for popular software, i >> think macports popularity could increase significantly and that is the >> perspective from which i penned this topic. >> >> maybe no one cares about that though lol. >> >>> >>> >>> >>> Ken >>> >>> >> >> >> >> Thanks, >> Gagan >> Thanks, Gagan
