> On Sep 29, 2024, at 10:00 AM, Ken Cunningham
> <ken.cunningham.web...@gmail.com> wrote:
>
> regarding nodejs…
>
> if you look in Trac, you will find nearly 400 tickets about nodejs versions.
>
> many of them relate to how some new nodejs version won’t build on some older
> OS where the previous version of nodejs did build.
>
> when this happens, people look to see what has changed to beak the build. if
> it is something relatively easy, like a new compiler is needed, we fix it.
> Often it is related to changes in the MacOS SDK, however. To support current
> systems, various code changes are made, and those changes break older systems.
surprisingly, in this case, it is “simply” a libcxx issue and two warnings that
have been treated as errors.
i think the maintainer for them (ciserlohn or whoever) should use my guidance
but eventually i will get to upping 14/18 (and probably 20 if it has the same
issues as the other two) and using your macports-libcxx.
>
> To a limit, we can work around these changes sometimes.
>
> But there comes a point where the compatibilty code is too unweildy and
> burdensome to maintain, and when that happens, we cut off certain older
> systems in the supported platforms section of the Portfile and move forward
> with what we can support.
>
> So it is not usually right to say “nobody ever tried to build it”…. in almost
> all cases, it was tried, and at a certain point, the game was called. This
> effort is rather unique to MacPorts, by the way… most projects would not do
> this, but would instead go with upstream’s supported systems and call it at
> that. Legacysupport and macports-libcxx (both of which I initiated) have made
> the older systems support much simpler.
>
> But even then, there is a limit …
i agree with everything you’re saying, especially with newer OSes being
released every year (stupid but you guys have a brand to maintain, i get it).
but i just don’t like the attitude of the brew team. it reeks of kids who got
ARM macs and think they’re ready to take on the world (i don’t care about who
they actually are).
they love to tell us IT’S UNSUPPORTED. DON”T FILE TICKETS. maybe that’s because
they don’t want their github issues to get bogged down, but i don’t like it.
i also think the very strong skills of the very small group of macports
maintainers overestimates the capabilities of a typical ports/brew leecher.
these people don’t know how to build things outside of an easy run.
-this is best shown by your disclosure of the 400 nodejs tickets, yet
none of them could read the errors in the log like the macports installer tells
them to?
-further, and i think this is probably the harder part (when
you start out, anyways): edit the portfile to treat the two warnings-as-errors
as their “-Wno” equivalents and try to build again?
-at that point they would have seen that all that was
required is a new libcxx
but i digress. i know the team is strong, concentrated, but also very small.
i don’t know how to do upstream changes or make upstream patches for revisions,
but my plan will be to first submit a patch for nodejsX that:
-removes the >=10.9 requirement,
-adds conditional arguments for <10.9 platforms that
-adds macports-libcxx as a dependency
-inserts the two -Wno- flags
i will then pull this change from my machine to test it.
if it goes well, then i think we will grow very quickly.
i guess i will then ping the gdb maintainer to tell them we need a newer libcxx
for older systems (i don’t know where that cutoff is, you would).
in both cases where macports-libcxx is required, i find it easier to simply add
-L/opt/local/lib/libcxx to the ldflags. not sure if that’s bad form or not.
then, a more lofty goal would be to eventually get lldb-xx working. however
these do require the SDK and this is where i have to figure out what to do.
-are we allowed to pull the SDK as an intermediate build dependency?
- mozilla does something for their artefact toolchain but they
don’t allow people to download the toolchain directly from them because of some
kind of intellectual property thing with APPUL.
i remember trying to get higher lldbs to build without much luck, but that was
due to my mistaken use of libcxx instead of macports-libcxx, and my
unwillingness to screw with the SDKs to see what would work.
-i have never thought to test how lldb would behave after being
built and the SDK was removed, so there are a lot of things here i need to look
at.
the gdb is useful but it doesn’t resolve symbols the way the old lion gdb does,
which i will also look at after i get this firefox to behave on 10.7
>
>
>
>> On Sep 29, 2024, at 07:56, Gagan Sidhu via macports-dev
>> <macports-dev@lists.macports.org> wrote:
>>
>> 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
>>> <ken.cunningham.web...@gmail.com> 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
>>>>> <macports-dev@lists.macports.org> wrote:
>>>>
>>>>
>>>>
>>>>>> On Sep 28, 2024, at 11:14 PM, Ken Cunningham
>>>>>> <ken.cunningham.web...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev
>>>>>>> <macports-dev@lists.macports.org> 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
>>
Thanks,
Gagan
