Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

Two of the libgccs are stubs, the rest are not. so it is pretty much as bad as it looks.

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

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

Re: cmake-devel --> cmake coming .... please test if you care to

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

cmake-devel --> cmake coming .... please test if you care to

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

Re: inserting -stdlib=libstdc++ into cxxflags

sorry, clang-11-bootstrap > On Mar 23, 2024, at 00:01, Ken Cunningham > wrote: > > the clang-10-bootstrap port builds against libstdc++ now. > > K

Re: inserting -stdlib=libstdc++ into cxxflags

the clang-10-bootstrap port builds against libstdc++ now. K

Re: GTK on PowerPC: does anyone have it actually working?

> 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

Re: GTK on PowerPC: does anyone have it actually working?

> 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

Re: GTK on PowerPC: does anyone have it actually working?

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

Re: GTK on PowerPC: does anyone have it actually working?

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

Re: GTK on PowerPC: does anyone have it actually working?

> 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

Re: How to force run tests as non-root?

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

Re: How to force run tests as non-root?

in the 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 b

Re: How to force run tests as non-root?

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

thank you for the arm64 sonoma buildbot, Ryan

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

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

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

Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

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)

Key universal build failures

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

Re: Sonoma Apple Silicon build machine

no Sonoma arm64 builder yet:build.macports.org

Re: Xcode PortGroup: Xcode compiles code twice?

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

Re: VLC for PowerPC: make a separate port or modify existing?

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 totall

Re: VLC for PowerPC: make a separate port or modify existing?

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,

Re: VLC for PowerPC: make a separate port or modify existing?

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.

Re: Go Ports: Update PG to Ensure Ports Aren't Built if Version Required Not Available

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

macports-legacy-support PR 61 could be the end of Tiger support for MacPorts....

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

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

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

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

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: rldicl / rldicr for 32-bit powerpc?

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

3272 R supporting ports ...

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

Re: [MacPorts] #66723: pcre2 @10.42: no such instruction: `lzcnt %eax, %eax'

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

some jackass hosed the wikistart page

don't recognize the username

Re: For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

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.

Re: For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

thanks, that looks like a good start !

For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

just thought I'd point that one out, for interested folks. Best, Ken

Re: Legacy Support for GHC-Based Projects

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 > wrote: &

Re: ports website says port has been deleted ... but it is there.

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

ports website says port has been deleted ... but it is there.

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

Re: Legacy Support for GHC-Based Projects

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

Re: Legacy Support for GHC-Based Projects

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

Re: Legacy Support for GHC-Based Projects

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

Re: Location to store Rust binaries

Here is a commit where I installed a binary from the packages server onto a different system than it belonged to. Something similar might work to install the 10.9 binary of rust-bootstrap on 10.5 through 10.8…

Re: Location to store Rust binaries

although the 10.9 one needed has not as yet been built it seems.You would also have to manually access and download the 10.9 binary on older systems, as the automatic mechanism to install it wouldn’t work where it’s needed.KOn Dec 22, 2022, at 05:02, Ken Cunningham wrote:they are thereIndex

Re: Location to store Rust binaries

they are thereIndex of /rust-bootstrappackages.macports.orgOn Dec 22, 2022, at 01:30, Chris Jones wrote:On 22 Dec 2022, at 4:02 am, mcalh...@macports.org wrote:As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.The problem is that the Rust binaries

Re: Dev guide updated for github/easy instructions?

I believe you’re looking for this:4.6. Local Portfile Repositoriesguide.macports.orgOn Dec 19, 2022, at 07:05, Watson Ladd wrote:On Mon, Dec 12, 2022, 1:55 PM Nils Breunese wrote:Does https://guide.macports.org/chunked/project.github.html help?A bit. What I don't know how to do

Re: The State of Rust in MacPorts Today

It looks like Marcus is working on this. K

Refined Github

For anyone who uses GitHub a lot, like the people on this list likely do, I came across Refined Github a few months ago, and I find it is quite helpful. It’s browser extension that adds considerable functionality to Github, basically. Thought I’d share:

Re: using /usr/bin/python3 on Ventura +

/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk" ../llvm-9.0.1.src Exit code: 1 I think we have to spec the pythons, rather than mess around with the system versions. It works sometimes to use the system versions, but not reliably enough to count on all the time. Ken > On Nov 26,

using /usr/bin/python3 on Ventura +

Trying to sort out some builds that need a python, as python2.7 is now gone from /usr/bin on newer systems. It looks like you can reliably use /usr/bin/python3 on these systems if you have either the CLTs or Xcode installed. The version is currently 3.9.6 on Ventura, and may not be the same

Re: having the "+test" or "+tests" variant propagate causes unexpected builds

I wonder if there was consideration given way-back-when to the idea of having NO propagation of variants at all. Anything you wanted to apply to every port, you would put in variants.conf. Otherwise, your variant applied to the port you were currently installing, and that is it. To me —

having the "+test" or "+tests" variant propagate causes unexpected builds

Various ports implement a “test” or “tests” variant to allow extra features and deps required for testing to be enabled. This variant, when requested, will propagate up the chain to all the ports, however. There is no real use case where someone would desire the test/s variant to propagate

Re: MacPorts 2.8.0-beta1 now available for testing

the only other thing I noticed was that these helpful pre-fetch messages were no longer being displayed: https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103 Instead there was just a message saying the build was known to fail,

transient error with macports-base 2.8: Error: Unable to execute port: sqlite error: another row available (100) while executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=109

FYI, I saw this issue after upgrading to macports-base 2.8 on 10.13 from current git master 2.8 release: $ sudo port -v destroot fluxbox Error: Unable to execute port: sqlite error: another row available (100) while executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=109 $ sudo

Re: what's with the C++ extension?

As per the ticket, I noted system apps (like iCal) crash when I upgraded the libc++ on Lion to the one we supply with libcxx, so that, for me, is unreliable. I didn’t try every system or every app of course. Mixing libc++ versions in one executable’s dylib space crashes unpredictably

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

Steve, some thoughts, as I helped you fix issue this last time. > Also, I’m perplexed with this doesn’t just work with the default MacPorts > compiler.cpath and compiler.library_path settings. It seems this prebuilt bootstrap library you are using: >

EGL support on MacOS?

I am not an expert on OpenGL support on any system, just trying to get things built, and looking for someone who might know more about it for ideas... The linux world seems to be moving towards EGL based on a number of recent changes I have seen in webkit2-gtk, gtk4, and other places, that I

Re: ld: waning messages -- Frameworks out of sync.

cript. > > If you used a different approach, please let me know. > > Rob > -- > *From:* macports-dev on behalf > of Ken Cunningham > *Sent:* August 18, 2022 2:34 PM > *To:* MacPorts Developers > *Subject:* Re: ld: waning messages -- Frameworks out of sy

Re: ld: waning messages -- Frameworks out of sync.

> Otherwise, one needs to set SDKROOT as follows: > export SDKROOT=$(xcrun --show-sdk-path) > It is best to set SDKROOT in one's ~/.bash_profile If you do that, you will possibly override MacPorts setting of SDKROOT, and this is likely to cause you many problems when building ports. I would

Re: compilers PortGroup

> Error: Rank mismatch between actual argument at (1) and actual argument at > (2) (rank-1 and scalar) > To work around this, you need to add -fallow-argument-mismatch to the FFLAGS > inside Makefile: Funny, that is exactly the argument that: compilers.allow_arguments_mismatch yes is supposed

Re: compilers PortGroup

> :info:build 595 | call isortii(nodef,iorder,nopes,kflag) > :info:build | 1 > :info:build Error: Rank mismatch between actual argument at (1) and actual > argument at (2) (scalar and rank-1) > :info:build make: *** [gencontelem_n2f.o] Error 1 perhaps it might be worth trying this option?

Re: Using on macOS 10.13 with clang++-mp-13

> On Jul 13, 2022, at 2:33 PM, Ryan Schmidt wrote: > > On Jul 3, 2022, at 13:38, Ken Cunningham wrote: > >> You can (sometimes) use macports-libcxx to get past this. This however >> introduces two versions of libc++.dylib into the softare mixture, and this >&g

Re: Using on macOS 10.13 with clang++-mp-13

This is an issue that will need solving, otherwise as filesystem is used more (and it seems popular) all the systems prior to 10.15 will be left behind. Filesystem uses features in libc++.dylib that are only present in 10.15 and newer. You are blocked from trying to use them on 10.14 and below by

Re: help with a regex please

thanks Fred, saw your answer afterwards, much appreciated. Ken

Re: help with a regex please

> > I would think: > s/--host(_alias)?=[^ ]*//a > > On Sun, Jun 19, 2022 at 3:34 PM Ken Cunningham > mailto:ken.cunningham.web...@gmail.com>> > wrote: > to fix the universal build of some ports, eg jemalloc, I would like to strip > out the host b

Re: help with a regex please

> On Jun 19, 2022, at 3:24 PM, Joshua Root wrote: > > On 2022-6-20 06:34 , Ken Cunningham wrote: >> to fix the universal build of some ports, eg jemalloc, I would like to strip >> out the host bits from these text strings, eg convert this: >> echo "--prefix=/

help with a regex please

to fix the universal build of some ports, eg jemalloc, I would like to strip out the host bits from these text strings, eg convert this: echo "--prefix=/opt/local --with-jemalloc-prefix= --host=aarch64-apple-darwin21.5.0 host_alias=aarch64-apple-darwin21.5.0 CC=/usr/bin/clang” to this: echo

Re: MacPorts Status

> If you are looking for some serious effort, it's the wrong > place; there is none here, they are all volunteers sadly... > > That's what I said, no coherence or coordination. > So what are your reasons to not use HomeBrew? > The right questions is how it needs to be, > probably more on the

Re: Reason for rpath usage on arm64

have no affect on the final installed files. Best, Ken On Sun, May 29, 2022 at 23:56 Ryan Schmidt wrote: > On May 30, 2022, at 01:01, Ken Cunningham wrote: > > > ah yes, your question was arm64-specific so that led to the gcc > assumption. > > > > the way the cmake

Re: Reason for rpath usage on arm64

be changed. K On Sun, May 29, 2022 at 22:17 Ryan Schmidt wrote: > On May 24, 2022, at 10:22, Ken Cunningham wrote: > > > >> Does anyone know why things seem to be using rpath on arm64 builds > > > > Basically, it comes down to the fact that Apple has disallowed > D

Re: Reason for rpath usage on arm64

Oh, nothing whatsoever to do with arm64 specifically. This is going to affect all gcc builds on all darwin-supported architectures once Iain pushes it through to all the branches he plans to keep supporting. On Tue, May 24, 2022 at 9:50 AM Joshua Root wrote: > On 2022-5-25 01:22 ,

Re: Reason for rpath usage on arm64

That comes right from Iain - here's the relevant gcc ticket I believe: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590 I'm sure Iain would be delighted to find a way around this. On Tue, May 24, 2022 at 9:50 AM Joshua Root wrote: > On 2022-5-25 01:22 , Ken Cunningham wrote: > &

Re: Reason for rpath usage on arm64

> Does anyone know why things seem to be using rpath on arm64 builds Basically, it comes down to the fact that Apple has disallowed DYLD_LIBRARY_PATH to work on newer systems. gcc for Darwin has one developer working on it, practically. Iain. He has been maintaining it for 10+ years, wrote the

Re: latest git version no longer detected by base ==> and it is a pain to use

the new git is causing headaches for me too. It delivers errors based on the ownership of directories above it, to address this: https://github.blog/2022-04-12-git-security-vulnerability-announced/ which means that any kind of git work in the macports trees (owned by macports) even as root

Re: [10.6.8] certbot & pyOpenSSL problems

I used this set of instructions and the tool referenced in the first comment myself: https://www.youtube.com/watch?v=EJA4OUIDa7Q to upgrade the firmware in a macmini 1,1 to 2,1, to allow it to see the rest of the installed RAM. It was, for me, very quick and very painless. As you noted,

Re: [10.6.8] certbot & pyOpenSSL problems

> System Version: Mac OS X 10.6.8 (10K549) Kernel Version: Darwin 10.8.0 It appears that you are running a 10.6.8 system (on a macmini, I think I saw?) and I think you appear to be using it as a server for various things. In another spot, I see that it is a 32bit EFI Mac: > platform:

Re: OWL - wayland for mac

In fact I have OWL running on my Mojave system now. It built in about 10 minutes last week, with only minor tweaking. However, so far I can only get wayland clients to connect to it, and indicate a successful connection, but not display anything. I think perhaps the supported wayland

Re: port:libcxx - why so old

> On Nov 28, 2021, at 12:30 PM, Ken Cunningham > wrote: > >> Hi, >> >> Judging from the version number, port:libcxx ships a version that's long >> outdated. Is there a reason for that, like it's the latest version that >> builds on all OS X vers

Re: port:libcxx - why so old

> Hi, > > Judging from the version number, port:libcxx ships a version that's long > outdated. Is there a reason for that, like it's the latest version that > builds on all OS X versions that require the libc++ conversion? > > I have a local version that is currently at v8.0.0 on my 10.9.5

Re: upgrade to openssl 3.0.0

rts/pull/12514> >> >> >>> On 6 Oct 2021, at 5:46 pm, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote: >>> >>> I’m working on the basic changes to implement my suggestion at the moment. >>> Once that is there testing specific po

Re: upgrade to openssl 3.0.0

12:54 PM Fred Wright wrote: > > On Mon, 4 Oct 2021, Christopher Jones wrote: > >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham < > ken.cunningham.web...@gmail.com> wrote: > >> > >> I was hoping to move this along for the overwhelming benefit of the > &

Re: upgrade to openssl 3.0.0

ll live alongside > the current ones. A few ports could be tested against it, and as and > when we are ready the default can be flipped again to point to it. > > Chris > > > On 04/10/2021 10:24 am, Christopher Jones wrote: > > > > > >> On 2 Oct 2021

Re: upgrade to openssl 3.0.0

grated to use the new PG individually > as and when we want. > > Chris > >> On 2 Oct 2021, at 6:17 pm, Ken Cunningham >> wrote: >> >>  >> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that >> will let many previously

Re: upgrade to openssl 3.0.0

All the pythons build against openssl 3.0.0, so that python issue with all it's trail-down conflicts will disappear with the upgrade and python revbump. A very very large % of ports do as well (and those that don't now soon will, as everyone moves to openssl 3.0.0 as the default, which homebrew

upgrade to openssl 3.0.0

openssl 3.0.0 is out, with a new and very favourable Apache-2 license that will let many previously non-distributable ports become distributable. However, there are 758 ports that indicate they link against openssl. That is a daunting number of ports indeed. One option might be to move all of

Re: changing 'configure' options for testing

es laid out in the same order as the port phases): > > > > pre-test { > > if {![variant_isset tests]} { > > ui_error "'tests' variant must be activated to enable test > support" > > error "Please enable the 'tests' variant

Re: changing 'configure' options for testing

On 2021-09-28 7:44 a.m., Daniel J. Luke wrote: On Sep 20, 2021, at 10:20 AM, Daniel J. Luke wrote: On Sep 20, 2021, at 8:15 AM, Frank Dean wrote: Daniel J. Luke writes: The newest version of clamav uses cmake for builds. In the 'configure' stage, I have it disabling tests because

Re: Help offered (macOS VMs)

I find Parallels is also very good for macOS VMs. I have a 24-core MacPro 5,1 with 32GB RAM that I mostly use for systems I don’t have as hardware, and have VMs set up in Parallels for MacOS 10.5 through BigSur. I usually give a dozen cores and 16GB of RAM to the VM when I’m working with it,

Re: Haskell Stack Ports on Apple Silicon

> On Aug 15, 2021, at 5:16 AM, Steven Smith wrote: > >> Cannot install shellcheck for the arch 'arm64’ because IF shellcheck had supported_archs x86_64 in the Portfile, it should never try to install the arm64 arch in the first place. So I’m guessing probably that was missing. It seems

Re: Haskell Stack Ports on Apple Silicon

> On Aug 14, 2021, at 7:13 PM, Joshua Root wrote: > > On 2021-8-15 11:52 , Steven Smith wrote: >> stack (and ghc, cabal) can only build x86_64, so it’s an x86_64 binary that >> runs on the M1 (whether built on x86_64 or arm64). >> The problem is that with the current supported_archs setting

Re: Haskell Stack Ports on Apple Silicon

You could override it, in pandoc or in the PortGroup: depends_skip_archcheck-append stack

Re: Haskell Stack Ports on Apple Silicon

I don't think it's overly simple to guess what might actually happen, or work. You have to try it various ways, and as Ryan says, I guess also try it when pandoc is pulled in as a dependency rather than directly installed, and see. The automatic fallback to other supported arches (eg arm64 ->

Re: Haskell Stack Ports on Apple Silicon

> I’d like to start hacking a Portfile update that will either compile pandoc > on the M1 with stack, or install the x86_64 binary and hope it runs, like the > x86_64 stack binary does. You won't be surprised to find out I did that exact thing about a year ago:

glib2 update to 2.62.5

Our glib2 port is severely out of date, and has been preventing port updates of some ports for a while now. The latest is gimp2, and so the pressure is on for that now. The glib2-devel port is considerably newer (although not current), has been out since February, and other than a couple of

re: Meson & non-Xcode compilers -- esp older OSX versions

nothing to do with meson or older compilers or @rpaths in general. the otool in cctools 949 does not call llvm-objdump-11+ (including -devel) with full args it likes. (llvm-11+ changed their supported args. ) That is why cctools defaults to llvm-10. don't use cctools +llvmdev unless you're

Re: We will need an isolated gcc c++11 bootstrap compiler

t libstdc++ is set to look in it's own tree for libstdc++ first, so it could be self-contained if we copy in libstdc++ from gcc6-bootstrap after it is built. That potentially gets us out of a whole lot of "clang_dependency" hell. Ken On Tue, Jul 6, 2021 at 12:33 AM Ken Cunningham <

  1   2   3   4   5   6   7   8   >