First of all, I’ve been pretty strongly attacked, as you can see.
Gagan has been around MacPorts for about two or three months. He has two
commits so far to his name:
https://github.com/macports/macports-ports/commits?author=i3roly
You can feel free to read the entirety of our interaction in th
> Except of course when someone decides to inflict a
> new compiler on it when the old one was working fine.
>
> Fred Wright
Yes, after I last updated the gcc ports on older systems, I also then left
gcc-7 as the default compiler for a very very long time specifically to avoid
problems -- and
MacPorts defaults all builds on 10.6 to libc++, and has done for YEARS now,
exactly so that supporting 10.6 won't be a huge, silly project of workarounds.
libsdtc++ is supported only so far as it takes to bootstrap libc++
Everything else you said was pretty much drivel, as usual, and I'll just l
Well -- of course 10.6-PPC needs lots and lots and lots and lots of special
workarounds.
10.6-PPC is basically 10.5 PPC wearing lipstick and a wig.
It is very very different from 10.6 / Intel / libc++. It builds with gcc, not
clang. It links against libstdc++, nott libc++. It does not have the
I'm done with Tiger, and it's a pain to keep supporting it.
So +1 from me.
Ken
PS. -- I personally have absolutely no intention of ever supporting efforts to
shoehorn MacPorts into the pre-beta of 10.6 stolen from from the Apple Dev
meeting, and agree it is just plain frickin' silly to have a
It's a long time since I thought about why the libunwind port is/was needed on
10.6, but here's one clue from many years ago about it.
https://github.com/macports/macports-ports/blob/676e6061b3a0150b4dff2ef682685092d71b8da4/devel/libunwind/files/0001-fix-_dyld_find_unwind_sections-for-pre-10.7.-
> > As of 10.7, libunwind was rolled into libSystem.
>
> No, Apple started providing it in 10.6 - see the headers and libSystem.
>
Maybe, I will check -- but I do know the libunwind from the libunwind port is
needed for some current ports to build on 10.6 and not on 10.7+
exact details as to w
I guess it's about time we addressed the issue with libunwind.
libunwind is involved in stack traces and exception handling.
it is a separate library on linux and on MacOSX < 10.7.
As of 10.7, libunwind was rolled into libSystem.
Jeremy set up a libunwind port years ago to support older systems
So the reason Jeremy set these tool wrappers up to be invoked by xcrun is that
xcrun adds a number of useful default settings ("sugar") and envvars to the
toolchain.
This does things like spec the appropriate sdkroot, etc… a reasonable summary
is here:
https://keith.github.io/xcode-man-pages/
These scripts have worked perfectly for years.
They work fine for me now, and on all the buildbots.
Please explain or demonstrate exactly what problem you believe you are
experiencing. The problem is most likely in your setup.
Ken
Sent from my iPhone
> On Dec 25, 2024, at 9:47 AM, Gagan Si
on 10.6 ppc with gcc-14, so perhaps the OS
> issue, not an arch or compiler one.
>> On Dec 20, 2024 at 18:41 +0800, Riccardo Mottola via macports-dev
>> , wrote:
>> Hi,
>>
>> Ken Cunningham wrote:
>>> https://trac.macports.org/ticket/71601#comment:3
>
today.. even if it is a 2x 1GHz G4
> with 2GB of RAM it took quite a bit. The first attempt froze the terminal, so
> I restarted using xterm and it worked - maybe just by luck.
>
> It also proves that GCC is very slow on PPC, compared to the MacBook which is
> nominally maybe 5
> On Dec 17, 2024, at 1:49 AM, Riccardo Mottola via macports-dev
> wrote:
>
> Hi,
>
> I noticed the gcc14 upgrade has been merged. I previously tested it on 10.5
> x86 and succeded.
>
> Now I want it "official". On the system where I tested, I swhichted again to
> rsync repository, hiding
> On Dec 7, 2024, at 22:25, Joshua Root wrote:
>
> On 8/12/2024 05:55, Ken Cunningham wrote:
>> The gcc8 portfile, for example, contains this at the top:
>> platforms {darwin >= 10 < 15}
>> and then this lower down, near the libgcc8 stub port:
>
I'm trying to understand why I see this error when trying to install gcc7 on
10.5 PPC, using the PR we are working on in
https://github.com/macports/macports-ports/pull/26655 to update the default gcc
compiler on older systems to gcc14.
gcc 8, 11, 12, and 13 are not currently enabled for system
On 2024-12-03, at 9:52 AM, Ryan Carsten Schmidt wrote:
> On Dec 3, 2024, at 11:20, Chris Jones via macports-dev wrote:
>>
>> It could be the linker version(ld) is also too old in this case. If you are
>> using the system provided one try with a newer one.
>
> You're right.
>
> I already had
> On Nov 23, 2024, at 9:35 AM, René J.V. Bertin wrote:
>
> Hello,
>
> This is mostly a public service announcement for those grappling with e.g.
> GTk4's new requirements and/or XQuartz in general.
>
> https://github.com/owl-compositor/owl/issues/12
> (esp. https://github.com/owl-compositor
> On Nov 22, 2024, at 03:18, Chris Jones via macports-dev
> wrote:
>
>
>> So the very first thing that someone should do is fix these three ports
>> libgcc8
>> libgcc10
>> libgcc11
>
> See
>
> https://github.com/macports/macports-ports/commit/eea28397c811c477a04407cbe3c105c76efd9219
>
>
Sent from my iPhone
> On Nov 21, 2024, at 7:17 AM, Chris Jones via macports-dev
> wrote:
>
>
>
>> On 21/11/2024 3:11 pm, Chris Jones via macports-dev wrote:
>>> On 21/11/2024 3:02 pm, Ken Cunningham wrote:
>>>
>>>> On 2024-11-21, at 6:56
Sent from my iPhone
> On Nov 21, 2024, at 7:11 AM, Chris Jones wrote:
>
>
>
>> On 21/11/2024 3:02 pm, Ken Cunningham wrote:
>>> On 2024-11-21, at 6:56 AM, Chris Jones wrote:
>>>
>>>
>>> On 21/11/2024 2:49 pm, Ken Cunningham wrote:
> On Nov 21, 2024, at 6:44 AM, Chris Jones wrote:
>
>
>
> On 21/11/2024 2:44 pm, Ken Cunningham wrote:
>>> On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev
>>> wrote:
>>>
>>>
>>>> OOTH: If gcc10 is available and
On 2024-11-21, at 6:56 AM, Chris Jones wrote:
>
>
> On 21/11/2024 2:49 pm, Ken Cunningham wrote:
>>> On Nov 21, 2024, at 6:44 AM, Chris Jones wrote:
>>>
>>>
>>>
>>> On 21/11/2024 2:44 pm, Ken Cunningham wrote:
>>>>> On
> On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev
> wrote:
>
>
>> OOTH: If gcc10 is available and installed, why would you want to call in a
>> full build of gcc13 unnecessarily to build the port?
>
> If you are suggesting the builds should check to see what the user has
> insta
ptions from users, as the gains are really not there in reality.
>
> Sure, lets discuss dropping some really old compilers, anything less than say
> gcc10 I think we could discuss removing, but for me the argument to remove
> the newer ones just does not real
On 2024-11-20, at 2:21 PM, Chris Jones wrote:
> Hi,
>
>> On 20 Nov 2024, at 10:00 pm, Ken Cunningham
>> wrote:
>>
>> Glad everyone gets to weigh in. If we can get a consensus to do this, we'll
>> try to do it as smartly as possible.
>>
&g
3, Ken Cunningham
> wrote:
>
>
>
>
>>> On Nov 20, 2024, at 06:35, Sergio Had wrote:
>>>
>>
>> On Nov 20, 2024 at 22:22 +0800, Ken Cunningham
>> , wrote:
>> Any concrete example of something gcc-14 breaks that gcc-13 builds?
>>
> On Nov 20, 2024, at 06:43, Sergio Had wrote:
>
>
>
> Serge
> On Nov 20, 2024 at 22:28 +0800, Ken Cunningham
> , wrote:
> once the default moves to gcc-14, gcc7 has to still work. You cannot have
> only one compiler available, that is too risky.
>
>
> On Nov 20, 2024, at 06:35, Sergio Had wrote:
>
>
> On Nov 20, 2024 at 22:22 +0800, Ken Cunningham
> , wrote:
> Any concrete example of something gcc-14 breaks that gcc-13 builds?
>
> A lot in fact, but for a reason orthogonal to toolchain as such.
Well, if the
To reduce ABI inconsistencies, Jeremy and others set up a system whereby we
have a single set of libgcc libraries that are used by all the gcc versions
supported on MacPorts. The latest version of a given gcc library is used by all
the gcc compilers.
So gcc5, for example, requires libgcc5, whic
Given that modern gcc is strictly required now, it is a tiny cost.
>
> After all, this is exactly how things have been on 10.6+, and nobody dies :)
>
> Serge
>> On Nov 20, 2024 at 22:04 +0800, Ken Cunningham
>> , wrote:
>>
>>
>>> On Nov 20, 2024, a
gcc versions is a pain.
Was hoping to see a tight way of keeping all the ports that use gcc simpler and
coherent, but if there truly is some reason for these non-current gccs to get
ongoing support in macports, I guess we are stuck.
Any concrete example of something gcc-14 breaks that gcc-
ners, since we get breakage reports which otherwise would not be there.
>
> To sum up:
> Right now old systems should be moved to gcc14, without modifying current
> arrangement. These two are independent issues.
> Upon consensus on libgcc is reached, that is to be addressed
mean for him more compilation because it
> builds another libgcc?
> 2) can we start with a minimal list and then "tweak" things if we discover
> some software not building and add e.g. one or two versions later?
>
> Ken Cunningham wrote:
>> The list of uniquely usefu
On 2024-10-04, at 3:22 PM, Mark E Anderson wrote:
> I thought that bug was related to SIP, but it doesn't seem to be. That's what
> I get for skimming.
This was suggested, which required turning off SIP to do:
https://trac.macports.org/ticket/66358#comment:55
I haven't tried it myself to see
Aha.
Never would have thought such an in-your-face thing would have even made it to
a ticket, much less one that has been sitting two months.
OK, thx
Ken
On 2024-10-03, at 4:24 PM, Ryan Carsten Schmidt wrote:
> On Oct 3, 2024, at 10:25, Ken Cunningham wrote:
>>
>>
>
Failed to parse file lang/rust-bootstrap/Portfile: rust_build.version (1.77.0)
must be newer than rust_build.stage0_versions (1.80.1 1.80.0)
Total number of ports parsed: 4
Ports successfully parsed: 3
Ports failed: 1
Up-to-date ports skipped: 39684
> On Sep 29, 2024, at 10:35 AM, Gagan Sidhu via macports-dev
> wrote:
>
> 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.
>
Well, if you do that, then you are not building agains
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
via macports-dev
> wrote:
>
>
>
>>> On Sep 28, 2024, at 11:14 PM, Ken Cunningham
>>> wrote:
>>>
>>>
>>>
>>>> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev
>>>> wrote:
>>>
>>
>&g
> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev
> 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 an
se 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]
>>
>>
&
check out:
https://ports.macports.org/port/macports-libcxx/
> On Sep 25, 2024, at 12:22 PM, Gagan Sidhu via macports-dev
> 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
wrote:On Wed, Sep 18, 2024 at 7:12 AM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:Of course, if you over-write 64 bit libs with 32 bit libs of the same name, or vice versa, in the same location, you are just hosed, ldconfig or no ldconfig.
Which is why linux has the lib32 and
either have to fix it (and everything) or
accept it can't be done.
I'm no expert -- there are experts around here.
https://forums.linuxmint.com/viewtopic.php?t=369512
K
> On Sep 17, 2024, at 5:41 PM, Fred Wright wrote:
>
>
> On Tue, 17 Sep 2024, Fred Wright wrote:
>&
ote:
>
>
> On Tue, 17 Sep 2024, Ken Cunningham wrote:
>
>> In my PPC Debian world, my 64-bit installation of Debian PPC is quite able
>> to run 32 bit software.
>>
>> Linux does this by putting the libraries into lib64 or lib32 subfolders, as
>> Linux doe
In my PPC Debian world, my 64-bit installation of Debian PPC is quite able to
run 32 bit software.
Linux does this by putting the libraries into lib64 or lib32 subfolders, as
Linux does not use "Fat binaries".
So if you go down this road with MacPorts, then presumably that ability will be
lost
required.
K
> On Jul 16, 2024, at 7:44 AM, Ken Cunningham
> wrote:
>
> The usual equivalent older construct is this:
>
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> {
>
> }
> [pool drain];
>
>
> which (AFAIK) does exactl
The usual equivalent older construct is this:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
{
}
[pool drain];
which (AFAIK) does exactly the same thing as:
@autoreleasepool
{
}
but just a little less beautifully.
Now the commit you referenced has this older construct still in
> without lobjc
>
> it’s the exact same as below.
>
> Thanks,
> Gagan
>
>> On Jun 10, 2024, at 10:17 AM, Ken Cunningham
>> mailto:ken.cunningham.web...@gmail.com>>
>> wrote:
>>
>> Yes but I still don't see -lobjc on your link line..
illa-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>> launchchild_osx.o:(symbol
>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x0)
>>>> referenced by
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/pr
es the same undefined symbol error.
>
> sorry for the duplicate message ken. forgot to send it ot the mailer.
>
>>
>>> On Jun 10, 2024, at 9:45 AM, Ken Cunningham
>>> mailto:ken.cunningham.web...@gmail.com>>
>>> wrote:
>>>
>>&
It's easier to help if we can see the link line you're using, but in short you
need to make sure that lobjc is in the link libs, sometimes by explicitly
adding it:
LDFLAGS="$LDFLAGS -framework Cocoa -lobjc"
K
> On Jun 10, 2024, at 8:08 AM, Gagan Sidhu via macports-dev
> wrote:
>
> hi team,
and
file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_python312/python312/work/Python-3.12.3/Python.framework/Versions/3.12/Python
?
On Thu, May 2, 2024 at 9:23 AM MacPorts wrote:
> #69892: python312 reportedly fails t
> On Apr 7, 2024, at 11:24 PM, Riccardo Mottola
> wrote:
>
> Hi,
>
> Ken Cunningham wrote:
>> Up to now, though, older systems have used gcc7, and in a few cases gcc5 or
>> gcc48 are used for specific issues. So those gcc versions may still be
>> neede
Once gcc13 is the default gcc used on older systems, it would be hoped that it
would cover off most needs.
Up to now, though, older systems have used gcc7, and in a few cases gcc5 or
gcc48 are used for specific issues. So those gcc versions may still be needed
... time will tell.
If the whole
Two of the libgccs are stubs, the rest are not.
so it is pretty much as bad as it looks.
It’s important you understand how the libgcc ports work now, to see how this
libgcc chain is set up and the problems it might cause on slower older systems
that have no buildbot.
Go to an Intel system like 10.7, uninstall all ports.
Disable the buildbot by clearing archive_sites in sources.conf
In general, the more a given system deviates from the main herd of ports, the
more likely there are to be problems and the less likely they are to be fixed.
To be honest, I don’t see why a new gcc port to be used only for powerpc is
needed.
My only question is whether to skip over gcc8-12, or i
ith me then to move 10.4–10.5 to libgcc13,
> since we should not have a disagreement anymore.
>
>
>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham
>> wrote:
>>
>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had
>> anything to do
supporting all the gcc versions between gcc 8 and 12 on older systems will be
quite a bit of work and require a lot of build time for poor users of these
systems.
To have libgcc7, the way it is now, you need to build libgcc13, 12, 11, 10, 9,
8, and then 7.
That is -- a lot of gcc building for
I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had
anything to do with why nobody had gotten around to updating the gcc version
used on older systems.
At least, it was not anywhere on my radar.
Just -- nobody did the legwork.
Ken
On 2024-03-28, at 11:47 AM, Sergio Had
verification.
K
> On Mar 27, 2024, at 02:29, Riccardo Mottola
> wrote:
>
> Hi Ken,
>
> Ken Cunningham wrote:
>> the cmake port is very very far behind.
>>
>> cmake-devel has been updated to the newest version currently available
>> (3.29.0) for most sy
the cmake port is very very far behind.
cmake-devel has been updated to the newest version currently available (3.29.0)
for most systems, and then newest supportable (3.28.4) for 10.7 and < 10.6.
Please try out if you care to, as cmake-devel should become cmake soon.
If you are interested in th
sorry, clang-11-bootstrap
> On Mar 23, 2024, at 00:01, Ken Cunningham
> wrote:
>
> the clang-10-bootstrap port builds against libstdc++ now.
>
> K
the clang-10-bootstrap port builds against libstdc++ now.
K
> On Mar 15, 2024, at 6:05 PM, Ken Cunningham
> wrote:
>
>
>
>> On Mar 14, 2024, at 4:07 AM, Sergio Had wrote:
>>
>> I guess you ask Ken, but anyway, does anyone have X11 GUI working for
>> `transmission-x11`
>
> transmission-x11 works
> On Mar 14, 2024, at 4:07 AM, Sergio Had wrote:
>
> I guess you ask Ken, but anyway, does anyone have X11 GUI working for
> `transmission-x11`
transmission-x11 works on 10.6 PPC.
(I had to do a little minor surgery on the transmission source code to make it
build with gcc7.)
Ken
5:33 PM, Riccardo Mottola via macports-dev
>>> wrote:
>>>
>>> Hi,
>>>
>>> Ken Cunningham wrote:
>>> gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.
>>
>> I'm hacking on GTK2 and GTK3 quartz support fo
nothing special.
if it’s not working for you, we can probably work through it in a ticket…
> On Mar 11, 2024, at 00:45, Sergio Had wrote:
>
> Thank you, Ken, this is helpful.
>
> Could you say whether you did any specific manual setup for X11?
>
>
>
>>>
> Sergey said:
> It looks like while even gtk4 builds fine with no hacks (and of course gtk2
> and gtk3 do), none of the apps built against then actually work. Everything
> crashes on start.
>
> Could anyone confirm if any GTK version is known to work on a PPC system, and
> point at a speci
On 25/2/2024 03:07, Ken Cunningham wrote:
>> Some of your macports installations are installed as the root user, instead
>> of the macports user.
>> This happened because there is no installer for 10.6-ppc to automatically
>> create the macports user. You have an op
master has no support for tests, as of now, so running it gonna fail anyway.)On Sat, Feb 24, 2024 at 11:24 PM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:Some of your macports installations are installed as the root user, instead of the macports user.
This happened because there
Some of your macports installations are installed as the root user, instead of
the macports user.
This happened because there is no installer for 10.6-ppc to automatically
create the macports user. You have an open ticket about this too, where I
pointed to the commands to be run to generate the
I installed fresh copy of the 2.9 base beta and then all new ports -- and it is
just ripping along now that many of them are already built.
Appreciate all your efforts keeping that going ... must be a ton of work.
Ken
I think you just don't realize the wreckage you've done.
Here is one of hundreds of your typical commits, although this is a simpler one
than most, to be honest.
The commit below has no purpose other than to allow the port to build as PPC on
10.6. And as that is really only of interest on 10.6-
There is no hiccup in MacPorts support for PowerPC systems, despite the
dramatic title of the PR.
Also there is no hiccup in support for older released Apple operating systems.
10.4 and 10.5 remain fully supported by MacPorts (although 10.4 might be on
last legs).
There is also no need (IMHO)
One of MacPorts' most significant differences from the other available package
mangers is it's preserved support for universal building. It is perhaps the
most impressive feature that MacPorts offers that the other package managers do
not (AFAIK).
However, at present, there are several core key
no Sonoma arm64 builder yet:build.macports.org
the xcode portgroup has always done this.
it builds everything in the build phase, and then builds everything again in
the destroot phase.
we have discussed this over the years and the previous conclusion was that this
was completely unavoidable, and we’d just have to live with it.
sometimes I
orks.On Sat, Aug 5, 2023 at 7:02 AM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:For playing videos on older systems, I think MPlayer is the way to go.Give that a try if you haven't.KenOn 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:I need an advice.We got VLC2 port (which is t
rov wrote:
>
> Don’t worry, I will not submit a PR for VLC unless it actually works with
> video. There is no point otherwise.
>
> If it does not, I just leave it. But for now it still makes sense to have an
> idea what to do with the port IF it works.
>
> On Sat,
For playing videos on older systems, I think MPlayer is the way to go.
Give that a try if you haven't.
Ken
On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:
> I need an advice.
>
> We got VLC2 port (which is totally broken for all systems) and VLC port,
> which installs pre-built binary. Neit
The last time I looked at this, go had moved on to use newer features of the
Security.Framework that couldn't be duplicated for older systems, so it was
stuck at an older pegged version.
I see here and there that some folks have managed to get newer versions of the
Security.Frameworks from App
/19047#issuecomment-1645344425On Fri, Jul 21, 2023 at 4:14 AM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:Some interested users discovered a deficiency in a part of legacy-support’s fdopendir implementation, and have come up with a fix.
due to the way the system on 10.4 works, howev
Some interested users discovered a deficiency in a part of legacy-support’s
fdopendir implementation, and have come up with a fix.
due to the way the system on 10.4 works, however, it looks like this fix will
not work on Tiger.
Unless someone comes up with a trick for this, this could be the en
gt;
> P. S. I wonder now if the current SDL2 gonna build with X11 backend and Cocoa
> off. Given that upstream concentrated efforts on skillfully breaking Cocoa
> beyond repair, everything else might be intact.
>> On Jul 20, 2023 07:15 +0800, Ken Cunningham
>> , wrote:
>
As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All
the ports use the Cocoa interface.
The modifications that were made to SDL2 by miniupnp to run on Tiger and
Leopard were fairly extensive, to an older version of SDL2, but they worked to
allow a number of ports that re
Adding it into cctools for the standard assembler to use whenever it might be
needed would be something of a project, to be sure...
However, patching it into a source file that needs it on a case-by-case basis
is probably a fairly trivial thing to do.
> On Jul 15, 2023, at 11:45 AM, Sergio Ha
Although I am truly awed by the amount of effort it required to generate this
many portfiles from the CRAN network, I'm curious how we are going to try to
keep this many R supporting ports even marginally up to date with their various
intertwined updates, dependencies, etc.
Without some kind of
Everything is always open for discussion, being an opensource, volunteer
project, for sure.
We may never do what I suggested, or perhaps some variation of it. Someone
may want to keep around clang-3.4 or 3.7 for some reason.
I just look for the simplest, most direct approach.
gcc10-bootstrap is
don't recognize the username
building boost 176 universal on my M1 bogs down in the selection of the
assembly context files. All the correct assembly files are not included, so the
link phase fails.
It looks fixable, but have to sort out how to get them right.
thanks, that looks like a good start !
just thought I'd point that one out, for interested folks.
Best,
Ken
d be a bit of a project. The cabal
config file needs some interesting additions to make everything work and force
the system libs...
Hope this is useful. Perhaps it might be used as a binary at least, until
things are further sorted.
Ken
> On Jan 28, 2023, at 6:57 PM, Ken Cunningham
>
oh, maybe it’s because the ports installation of macports does not accept the
extract.rename option yet because it hasn’t been updated yet…
K
> On Feb 3, 2023, at 07:55, Ken Cunningham
> wrote:
>
> Perhaps because the buildbots are down? Not sure why else this would say th
Perhaps because the buildbots are down? Not sure why else this would say the
port is deleted..
https://ports.macports.org/port/codeblocks-devel/
but here it is:
https://github.com/macports/macports-ports/blob/master/devel/codeblocks-devel/Portfile
Ken
t; stack as the build tool: https://trac.macports.org/ticket/66764
>
> Back to cabal.
>
>> On Jan 25, 2023, at 11:29 AM, Ken Cunningham
>> wrote:
>>
>> Stack from MacPorts doesn’t build on snow leopard, and I don’t recall it
>> ever built in previous years
’t stack-based pandoc also build back to Snow Leopard? Is this a
> MacPorts issue or a Haskell-world issue?
>
>> On Jan 24, 2023, at 11:56, Ken Cunningham
>> wrote:
>>
>> At least some of the buildbot ghc builds might be fixable — one of them
>>
At least some of the buildbot ghc builds might be fixable — one of them failed
due to a missing png-config I believe, for example.
Because of the way upstream builds ghc on macos, their older system support has
become more limited. They use homebrew, and current systems, with an older
deploymen
1 - 100 of 832 matches
Mail list logo