Re: virtualbox mojave fix

Oh, it would be great if I read that backwards, as I use VBox mostly for the 32bit guests. Thanks, Ken > On May 19, 2019, at 10:01 AM, Joshua Root wrote: > > On 2019-5-19 16:20 , Ken Cunningham wrote: >> BTW, VB 5.x is the last that supports 32 bit OS client versions, so if

virtualbox mojave fix

lots of people on this list would use virtualbox for at least some VMs, so I thought I'd save you some trouble perhaps. The latest update to Mojave has blocked the kext from installing, so you can't install or update VB any longer. If you boot into recovery mode and run this command from the

URGENT -- massive merge commit on macports/macports-ports

uh oh. Somebody better take quick peek that this last commit, please. Best, Ken

Re: URGENT -- massive merge commit on macports/macports-ports

ter) would be a bad idea and possibly > lead to trouble, so best to leave it, and hope the committer learns not to do > it again ;) > > Chris > >> On 21 May 2019, at 10:44 pm, Ken Cunningham >> wrote: >> >> uh oh. >> >> Somebody better take quick peek that this last commit, please. >> >> Best, >> >> Ken >

Re: flang port

Iain says he's already fleshed out most of it in his gcc5 darwin branch in his github repo. That guy is amazing. He wrote the whole objective-C 2.0 code for gcc himself, and has added most (perhaps all) of the darwin PowerPC support to llvm in his spare time. A one-man dev team. Ken

how to build a MacPorts installation with current security on any system

As this has recently come up again in the tickets and on the mailing lists, I thought I would write this process up so people can see how I do this on all my older systems (presently 10.9 and less). It’s possible this process could be improved further, but this is the process I use at present.

Re: Preparing for 2.6.0 beta

We might expect to see some breakage in ports that use xcodebuild on 10.6 to 10.8 once the default is libc++. I have tweaked (hacked) my own 10.6 sdk with symlinks to current cctools, clang, & ld64 at times to fix these errors. For general use, I wondered about using xcode's sdk overlay

Re: Preparing for 2.6.0 beta

oh no, bjarnehas to happen.! whatever issue might remain, we will fix. this will greatly simplify things for older systems, and keep them supported longer. Trying to build c++11 w clang against the gcc headers is driving me batty and causing way too much wasted effort... Ken

Re: [2.6.0-beta1 & Libcxx] clang-7.0 fails to build

of course we could also ask what is forcing clang 7 in the first place...most likely could be clang 8 used instead.

Re: Screwy Fetch Behavior

> I noticed that MacPorts was sometimes trying to fetch patch > files from distfile mirrors. > What's causing this and > how do I get around it? That happens if the patchfile being referenced in the Portfile does not exist in the files directory. Ken

Re: [2.6.0-beta1 & LibcxxOnOlderSystems] stack fails to build

I haven't dug in, but unless something has significantly changed, ghc needs to bootstrap from a prebuilt compiler that it downloads, and this prebuilt compiler does not run on 10.6.8, so you're out of luck until (at least) we figure out how to bootstrap something from a version of ghc that did

haskell 7 world

For users of the systems that can't run the current haskell 8.x software (at present at least) I extracted what i believe is the bulk of the haskell 7.x world and have it as a portfile overlay. It seems to work. pandoc installs and runs on 10.6.8, for example, as does HedgeWars. Perhaps it

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

> When you specify font name, XeTeX uses fc-config to find that font name, Sorry, I'm on this ipad and I answered a bit in the other mailing list. I knew you would know so much about latex! Just exactly what I was hoping for. So it appears that we (I at least) can't find some fonts be name when

Re: haskell 7 world -> moving to 8!

On 2019-09-12, at 7:02 PM, Ken Cunningham wrote: > > PPC is pretty much out, I think, because the llvm backend that haskell uses > can't produce quality PPC code... Actually -- that is not correct. I was under the impression that ghc used llvm as it's sole code generator base

Re: scope of configure.optflags, configure.compiler etc. command line variables

-Wl,-no_pie Is the linker option you were looking for. K

make mpstats a depends run on legacysupport?

To get a sense of how much our older systems support is used, I am tempted to make the mpstats port a depends_run-append for legacysupport., which is installed on all older systems. How awful do you think this might be? If totally unpalatable, could we at least make it an opt-out variant?

10.6.8 i386 buildbot offline

just a heads-up that this buildbot appears to have been offline a couple of days now K

haskell ghc / cabal / stack on 10.6.8

I think I have this sorted out now. These parts of ghc/haskell all seem solid enough, and with them everything else should work. They are all compiled on 10.6.8 (64 bit) and the cabal and stack binaries seem to work find on 10.14, so perhaps they will be useful for all systems that are not

Re: make mpstats a depends run on legacysupport?

I’ll add something like this to the legacysupport port notes https://lists.macports.org/pipermail/macports-users/2019-September/047273.html Better than nothing :> Ken

Re: haskell 7 world -> moving to 8!

On 2019-09-12, at 7:51 AM, Mojca Miklavec wrote: > > > Cool! > > Doesn't it work if you simply use this working ghc-bootstrap to build version > 8? > Or is Haskell too picky about what version of compiler you require to > build something newer, and you can only go forward one tiny step at a >

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

lace -E "s|(\{DejaVu\[\[:alnum:\]_\]*)\[\[:space:\]\]+|\\1|g" \ ${f} reinplace -E "s|(\{DejaVu\[\[:alnum:\]_\]*)\[\[:space:\]\]+|\\1|g" \ ${f} reinplace -E "s|\{(DejaVu\[\[:alnum:\]_\]*)\}|\{\\1.ttf\}|g" \ ${f} } Ken On 2019-09-12, at 4:32 PM, Ken Cunningham wrote:

latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

I'm working on making a newer bootstrap version of ghc for SnowLeopard. The ghc 8.0.1 build finishes on 10.6.8, but it wants to build the PDF documentation next, and texlive is erroring building the PDF. I know nothing about texlive. I know I might turn off the docs, but -- it took many hours

Re: haskell 7 world -> moving to 8!

On 2019-09-12, at 7:02 PM, Ken Cunningham wrote: > ghc is only C code. Well, C code + haskell of course. Not c++ . It's primarily the c++ exception handling Darwin ABI issue with PPC llvm that limits releasing clang-5+ for PPC to the wild. Ken

Thank you for defaulting to libc++ on older systems

I would like to thank everyone, especially Josh who did the bulk of the heavy lifting and Jeremy who initially designed the whole setup, for the work involved in making the default to libc++ happen for all these systems. Although, no doubt, we may find a few hiccups that need to be tweaked, on

RFC: MacPorts policy should be that docs should not be built or installed by default

the documentation that comes along with many ports often seems like a heavy and arguably needless burden: - huge bloat - lots of often onerous, massive, fussy build deps - often takes as much time to sort out doc building as building the port and, the big one : I bet almost nobody ever looks

Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?

ris Jones wrote: > > > >> On 27 Sep 2019, at 3:06 pm, Ken Cunningham >> wrote: >> >> I think it would be fair to invite everyone to try setting the default >> compiler list for a week on your own systems to our current macports clang >>

Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?

I think it would be fair to invite everyone to try setting the default compiler list for a week on your own systems to our current macports clang progression! Compilers are always ahead of the codebase by a couple of years. What are the clang-using Linux distros defaulting, I wonder? That might

Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?

> FYI clang-8.0, new default on 10.6.8, is very strict > > appears will have to add to blacklist on many ports So as much as I would have put clang-5.0 first as the default compiler if the system clang won't work, I understand that as some payback for all this older systems support effort,

Re: gcc/g++ failures after xcode11 update

> The issue is both macports clang and gcc rely (by default) on /usr/include > being present, and this is no longer present by default with Xcode 11 Not exactly. The full logic was outlined by Jeremy here: https://trac.macports.org/ticket/57612#comment:18

Re: Xcode 11 & SDKROOT on macOS 10.14

that cdtool stuff looks a bit unusual to debug: https://forums.developer.apple.com/thread/79439

libraw libstdc++ advice please

while tracking down an openmp issue in ImageMagick that appears to have been due to fopenmp flags in libraw > , we stumbled across the fact that libraw had a hard link to libstdc++ in it’s pkgconfig files. I removed

keeping software forks under MacPorts repo?

In #57751 Michael and I have been talking about how keeping up the patchset for qt4 would probably be easier with our own fork of it, with our patches added on. QT4 has a github repo here > and we could fork that to MacPorts repo, and add our

Re: keeping software forks under MacPorts repo?

> On Nov 9, 2019, at 9:06 AM, Ryan Schmidt wrote: > > On Nov 9, 2019, at 11:00, Mojca Miklavec wrote: >> >> But we would probably want to >> prefix the repository names (something like "fork_qt", "fork_llvm") to >> clearly distinguish them from our main repositories. > > I wouldn't

Re: error: thread-local storage is not supported

Let me say more Every MacOS system supports thread_local storage, from 10.4 Tiger PPC on up. Up to now, the base thread_local specifier introduced in MacPorts 2.6 has worked beautifully. There is no reason to manually specifiy any compiler other than that command. There is no reason to

Re: error: thread-local storage is not supported

> Clang 5 and above do support this () Clang 5 and above do support thread_local storage. what issue are you having? Ken

Re: error: thread-local storage is not supported

upports/29929949#29929949 > 2. https://developer.apple.com/videos/play/wwdc2016-405/?time=354 > 3. https://github.com/macports/macports-base/pull/161 > >> On Nov 21, 2019, at 5:10 PM, Ken Cunningham >> wrote: >> >> Well, I’ll be hornswaggled. >> >> Indeed it appears

Re: error: thread-local storage is not supported

gt; > Best, > Renee > > >> On Nov 21, 2019, at 12:52 PM, Ken Cunningham >> mailto:ken.cunningham.web...@gmail.com>> >> wrote: >> >> yes, clang 800+ supported thread_local. >> >> the open-source clangs support thread_local using libc++

Re: gcc7/libgcc7 problems

on PowerMac, and use that -- it would, naturally, have no such interaction with /usr/lib/libstdc++.dylib and therefore problem solved. So -- working on it. For now, libgcc7 7.4.x is magically immune, it appears, at least so far as we know, for now. K > On Dec 11, 2019, at 12:58, Ken Cunning

Re: gcc7/libgcc7 problems

thing we already have done that on 10.6 and up! Sooner or later this would have happened there too... K On 2019-12-15, at 12:13 PM, Ruben Di Battista wrote: > Isn't something similar to what patchelf does possible on macOs? Editing the > RPATH? > > On Sun, 15 Dec 2019, 19:06 Ke

gcc7/libgcc7 problems

We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in memory handling, possibly related to locale support, maybe some other thing TBA). We may have to bump epoch and roll back to last 7.4.x unless we can get

gcc7/libgcc7 problems

If you do decide to do this please only do it where needed, i.e. on i386 or 10.5 PPC. Newer systems that work fine with 7.5 should stay on that version. Hmm. May be too complicated to do that. gcc7 installs nothing much useful on newer systems anyway. Ah well, maybe Iain will fix it. My

Re: gcc7/libgcc7 problems

: > On 12/11/19, Ken Cunningham wrote: > > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 > > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in > > memory handling, possibly related to locale support, maybe some other > thing > > TBA

Re: How to handle ports that are still broken because of the icu upgrade

> I'm somewhat lost about how even manually address the problem. Should > clang-9.0 use /opt/local/libexec/libcxx-bootstrap/lib/libxml2.2.dylib? I have wrestled with this a few times as well. I believe, in the end, I solved it by deactivating clang-5+ (and xar?), and rebuilding libxml2 with

clang-8.0 very strict

FYI clang-8.0, new default on 10.6.8, is very strict appears will have to add to blacklist on many ports or otherwise surgerize code/standard setting — eventually will have to happen but all at once is daunting downgrading default compiler on 10.6.8 to clang-5.0 gets the rev-upgrade done once

How to have macports-built software use an alternate libc++.dylib ?

For purposes of testing newer libc++ versions, and as there are some new features in newer libc++ (filesystem, eg) releases that will soon become attractive, it would be desirable if we could find a way to build software against a different libc++ than the one in the system's lib directory. I

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

> Can you give specific examples, preferably with logs? On ppc, > macports-gcc compilers are preferred over macports-clang: > > > So I don't immediately see how what you describe could happen, unless > the

removal of cxx11 PG and pre-snowleopard systems having some issues

To no great surprise, as I didn’t bother to try it before now, the move from the cxx11 PG to the new compiler spec system seems to be having some issues on my older systems. MacPorts is calling in libomp and clang on PPC, which of course are not (presently at least) available. So you may see

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

PM, Joshua Root wrote: > > On 2019-10-7 12:58 , Ken Cunningham wrote: >>> Can you give specific examples, preferably with logs? On ppc, >>> macports-gcc compilers are preferred over macports-clang: >>> <https://github.com/macports/macports-base/blob/v2.6.1/src/port1

Re: Setting system gcc when `port select --set gcc app-gcc*` is set

You can’t make sure gcc means any particular compiler. One way or another this software needs to conform to normal rules, not the other way around. K Sent from my iPhone

Re: compiler compatibility on < 10.6

> It recently came up that base should always add the macports-gcc > compilers to the fallback list on ppc. What's less clear is what should > be done on Intel 10.5 and 10.4. > > Does anyone know with certainty: > > 1. Which versions of macports-clang (if any) work on these platforms > without

Re: Upgrade cctools unexpectedly failing

> I wonder if the SDK path is > baked into llvm-config-mp-7.0? Yep -- sheesh. Is there no end to this? Ken $ llvm-config-mp-7.0 --cflags -I/opt/universalnew/libexec/llvm-7.0/include -pipe -Os

Re: implementation of configure.env-append

tfiles with that method. K On Tue, Oct 8, 2019 at 9:25 AM Blair Zajac wrote: > > > > On Oct 8, 2019, at 1:59 AM, Ryan Schmidt > wrote: > > > > > > > > On Oct 6, 2019, at 14:05, Ken Cunningham wrote: > > > >> I think I have tried this enough ways to

Re: implementation of configure.env-append

Quite right, and that's of course what I usually do. And it works most of the time. But in some cases, ports don't run a configure phase, or it is not fully honored due to internal software tricks or malfeasance, or similar. So it is necessary to get the extra variables into the environment

Re: 2.6.0 features

I have come across several ports where variant c++ standards are needed, like gnu++11 for example, so perhaps setting the std automatically could lead to troubles... K

Re: Running buildbot-worker via launchctl

> If I run it manually then it works as expected. Permissions issue, maybe with pid file? K

implementation of configure.env-append

I think I have tried this enough ways to be close, but I just want to be certain. I want to *append* a value onto an existing environment variable from a Portfile. I don’t want to overwrite what is there in the environment variable already. adding for example this in the Portfile:

Re: implementation of configure.env-append

7:28 , Ryan Schmidt wrote: > > > > > > On Oct 9, 2019, at 12:04, Ken Cunningham wrote: > > > >> On Tue, Oct 8, 2019 at 1:59 AM Ryan Schmidt wrote: > >> > >>> No... it's the other way around... > >>> > >>> If

Re: implementation of configure.env-append

> > On Tue, Oct 8, 2019 at 9:25 AM Blair Zajac wrote: > > > > >> Maybe the MacPorts could raise an error if one attempts to set a variable > >> like LDFLAGS outside of configure.* ? > > Yes, MacPorts could do that. I don't think anybody's tried to write code to > do that yet. > > and

Re: Xcode bug (was: pymol crashing under Qt on Catalina)

> On Oct 13, 2019, at 7:26 AM, Joshua Root wrote: >>> >>> Ah, good to know. Do you have a link to Jeremy's statement out of curiosity? >> >> No I don’t, I only know this second hand from a comment by Ken... > > Ken? > Hey Ken, > > There's a bug in Xcode 11's llvm that is biting

Re: Pick up SDKROOT as the sysroot fallback.

> > I did not want to touch that at this point. The gcc bug report is still > > open, as far as I can see. > > > > If someone wants try a build using —with-build-sysroot instead, they are > > very welcome to try... > > > > Cheers chris > > > > Chris, > I'll try your changes with that hunk

Re: Pick up SDKROOT as the sysroot fallback.

> > Also, note that if you execute the buried clang compilers in > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > or /Library/Developer/CommandLineTools/usr/bin that they can't find the SDK. > Jack > The logic to add SDKROOT to the

Re: Xcode bug (was: pymol crashing under Qt on Catalina)

>> >> >> Thanks, >> Jeremy > > Hope that doesn’t mean 12 Apple lawyers will be calling me Tuesday. Happy (Canadian) Thanksgiving! (It’s cold up here, harvest comes a month earlier than down in the USA). Ken

Re: gcc won't build i386 with our cctools assembler hack

> On Tue, 25 Feb 2020, Ken Cunningham wrote: > > > building i386, gcc 5,6,7,8 misconfigures when our "as" redirects it to > > clang for assembly, following our hack in cctools to do that. the gcc > > build then fails. > > > > I have not so far be

Re: gcc won't build i386 with our cctools assembler hack

So, second notice / heads up on this. Plan is: to roll back to libgcc / gcc 7.4.x on 10.4, 10.5, and maybe on i386 10.6. to conflicts_build every clang version >= 5.0 when build_arch is i386 on every gcc version >= 5. and then this will perhaps stay like this forever, or at least until some

gcc won't build i386 with our cctools assembler hack

building i386, gcc 5,6,7,8 misconfigures when our "as" redirects it to clang for assembly, following our hack in cctools to do that. the gcc build then fails. I have not so far been able to overcome this other than: 1. deactivating all clangs 5+ prior to the build, to get the old gas or 2.

bin: dependencies not working at all?

Either I’m having a problem understanding bin: deps, or something is not working correctly with them. I’ve tried the same thing on several different machines, and always seem to get the same result. Specifically, I’m trying to trim down unrequired dependencies on some of the bootstrap ports

Re: bin: dependencies not working at all?

> > What stupid assumption am I making, or what am I doing wrong? > > When you actually install, the bin: dependency will be considered > satisfied by /usr/bin/perl. > > - Josh Well so it did. I had no idea it worked like that. port -v info and port -v rdeps did not help me much... Thank you —

ld64 circular dependency and bootstrapping thoughts

Touch complicated, hope I explained it clearly. Probably best not to read at half-time today :> Watch J-Lo instead... After a number of years at @274, ld6 @450 can now build with MacPorts. It matches Xcode 10.2. ld64 @450 supports the latest TAPI-requiring SDKs, new features, etc, and all

Re: ld64 circular dependency and bootstrapping thoughts

Ken > On Feb 2, 2020, at 3:39 PM, Ken Cunningham > wrote: > > Touch complicated, hope I explained it clearly. Probably best not to read at > half-time today :> Watch J-Lo instead... > > > After a number of years at @274, ld6 @450 can now build with MacPorts. It &g

Re: ld64 circular dependency and bootstrapping thoughts

> On Feb 4, 2020, at 8:26 PM, Ken Cunningham > wrote: > > 10.4 PPC (and Tiger) can likely upgrade to at least ld64-127 10.4 PPC (and Intel) I meant. K

cctools 927.0.2 update

The first cctools update in about 14 months looks ready to commit to me. This matches Xcode 10.2, and is the last one Apple has released so far. As a core component of macOS and MacPorts, touching almost every system, I would appreciate anyone interested to give this a review, try to break it,

Macports-ports repo getting pretty large -- 200MB

Not the end of the world with modern disks I guess, but quite a bit larger than I thought lately. There are a surprisingly large number of files > 50K in the repo, a considerable number > 100K, and some > 500K. Perhaps we might trim / compress / work on having them available as distfiles,

Re: Macports-ports repo getting pretty large -- 200MB

well now that is a full history repo...I should check just the current depth only one before I get too excited I suppose...but still was surprised by the large files in there... K

Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

looks like 7.1.0 is a very unusual, unlikely to be repeated soon, event. http://llvm.1065342.n5.nabble.com/LLVM-7-1-0-Release-td128369.html Ken > On Jan 16, 2020, at 07:56, Ryan Schmidt wrote: > > > >> On Jan 14, 2020, at 18:42, Chris Jones wrote: >> >>> On 14 Jan 2020, at 10:39 pm, Ryan

it might be useful to be able to enable specific configure commands only when running tests

It might be helpful if there was a configure command in the portfile that was only enabled when “port test” was run. Specifically, for example, something that would enable the following command: configure.args-replace --disable-tests --enable-tests only when tests were being run. I realize at

renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

We finally had a situation where the llvm-N.0 naming convention did not work out, and we have a port named llvm-7.0 now actually being llvm-7.1.0. This inaccuracy generates a "disturbance in the force”. AFAICT, this has not ever happened before, so we always got away with it. We can just live

Re: it might be useful to be able to enable specific configure commands only when running tests

rt in question. I do this with > >> sudo port install XYZ > … >> sudo port uninstall XYZ >> sudo port install XYZ +test > > Chris > >> On 18 Jan 2020, at 11:37 pm, Ken Cunningham >> wrote: >> >> It might be helpful if there was a con

gcc10 will default to fno-common

.GCC 10 will default to fno-common (previous versions default to fcommon). some breakage is anticipated here’s the suse tracker for package fall-out and a more complete description of the issue: https://bugzilla.suse.com/show_bug.cgi?id=1160244 K

Re: strange cmake error trying to install babl +universal

> On Jan 5, 2020, at 4:26 PM, Ryan Schmidt wrote: > > With what version of Xcode? > > MacPorts base doesn't allow universal builds when only the 10.14 SDK or later > are available (i.e. with Xcode 10 or later) since the SDKs don't have the > i386 parts anymore. > >

Re: strange cmake error trying to install babl +universal

> On Jan 5, 2020, at 4:17 PM, Ryan Schmidt wrote: > > > > On Jan 5, 2020, at 17:48, Ken Cunningham wrote: > >> $ sudo port -v destroot babl +universal >> Error: cmake cannot be installed for the configured universal_archs 'x86_64 >> i386' because

strange cmake error trying to install babl +universal

$ sudo port -v destroot babl +universal Error: cmake cannot be installed for the configured universal_archs 'x86_64 i386' because it only supports the arch(s) 'x86_64'. Error: Unable to execute port: upgrade librsvg failed cmake can of course be installed universal. Having said that, there is

Re: GSOC 2020

I would be very curious to see if a buildbot project might sort out how to test-build all the dependents of a suggested upgrade to a library for breakage. I recall hearing about one of the unix variants that had figured out how to do that. K

Re: gcc won't build i386 with our cctools assembler hack

Iain has sorted out what the error is. Apparently it is fixed in gcc9+, so I'll try those and see if they build i386 now. He is prepared to backport the fixes into gcc5 to gcc8 so that the i386 builds won't error out if clang/llvm is used as assembler. So once that is available, we can add

Re: gcc won't build i386 with our cctools assembler hack

I am discussing with the gcc darwin lead to see if any other options are available. Ken

Re: gcc won't build i386 with our cctools assembler hack

Iain's fix changes the assembly output to succeed if the assembler detected during the i386 gcc build is clang, but this is not an on-the-fly change, rather a configure-at-build change... so for our purposes, we will still need to force the older gas behaviour when gcc is built i386, so gcc

Re: new naming scheme for llvm/clang will cause wreckage fyi

> On Mon, 20 Apr 2020, Ken Cunningham wrote: > > > proposed new naming scheme for llvm & clang 10+ as prev discussed. > > explanation why in PR. Up to group, but will affect everything if it > > goes through. I'm fine either way, leave naming pattern as is or chang

new naming scheme for llvm/clang will cause wreckage fyi

proposed new naming scheme for llvm & clang 10+ as prev discussed. explanation why in PR. Up to group, but will affect everything if it goes through. I'm fine either way, leave naming pattern as is or change it. Once in, no going back... see K

Just another heads up / RFC --> Re: new naming scheme for llvm/clang will cause wreckage fyi

The suggested renaming of the clang/llvm/lldb ports to clang-10 instead of clang-10.0 going forward from clang-10 onwards will have repercussions in a number of places, should it proceed, as per the PR. For one, this does not work any more: configure.compiler=macports-clang-10 and that

Re: Need help diagnosing weird build error of mpv on Catalina

modules. going to cause us headaches. try building it without macports. my guess is that works. if so, try building in macports against the original Xcode SDK instead of the CLT SDK. K

Re: Need help diagnosing weird build error of mpv on Catalina

for some insight into the kinds of issues that may arise when trying to use modules and also mixing headers from different sources, look at this recent post on cfe-dev: This issue looks like it may take some work... k

is there a way to use MacPorts to use a local source folder as source for builds?

I would like to use MacPorts to work on several large projects hosted on github, that I clone locally and add incremental patches to. Think LLVM, qt4, qt5, etc, etc. During the MacPorts build, I would like MacPorts to use my local cloned folder of source as the source code for the build. For

Re: hfsinspect: src/crc32c/crc32c.c:29:13: error: instruction requires: Not 64-bit mode

On 2020-05-05 8:43 a.m., Paul de Vries wrote: On 2020-05-05, at 15:49, Ken Cunningham wrote: you are building a 64 bit executable, but trying to include 32 bit Intel asm, which won't work. hopefully there is 64 bit asm somewhere you should include instead, or some #define to set for 64

Re: hfsinspect: src/crc32c/crc32c.c:29:13: error: instruction requires: Not 64-bit mode

you are building a 64 bit executable, but trying to include 32 bit Intel asm, which won't work. hopefully there is 64 bit asm somewhere you should include instead, or some #define to set for 64 bit builds, or some way to turn off the asm, or ... some other way to not include 32 bit asm in a 64

Re: hfsinspect: src/crc32c/crc32c.c:29:13: error: instruction requires: Not 64-bit mode

> for the manual make i did git clone --recursive > > g you may be using the bundled crc then in the manual build, and some other crc is being found by macports in the macports build. I'd have to actually try to build it now to tell you anything more intelligent, but I have too many other

Re: gcc won't build i386 with our cctools assembler hack

prevent unexpected wreckage. > On Fri, 6 Mar 2020, Ken Cunningham wrote: > > > I am discussing with the gcc darwin lead to see if any other options are > > available. > > Maybe that will help. It's not easy for me to bug Iain with low-level crap like this that we created

make xorg-server a dependency of x11 ports?

Should xorg-server should be made a dependency of some key x11 component, so that when people install an x11 application, xorg-server installs and it actually works for them “out-of-the-box”. For example, CherryTree is apparently a very popular gtk application, and there was some pressure for

Re: make xorg-server a dependency of x11 ports?

> What I'm trying to avoid is having to add boilerplate code to hundreds of > ports. So I guess that means yet another portgroup to do this. But even that > -- editing hundreds of possibly optionally X11-using portfiles to insert the > inclusion of that portgroup only when X11 is actually going

Re: make xorg-server a dependency of x11 ports?

On Wed, 20 May 2020, Ken Cunningham wrote: >/i was imagining just one key port — gtk, or some other always installed />/required supporting lib — would do the test. / I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright Fill in yo

promote older systems support

there is considerable grousing on the homebrew forums about their ruthless policy for dropping support for systems more or less right after apple does, and some of those forum posts about this topic have many thousands of views. as you folks have put such effort into older systems support over

mariadb upstream is asking for some help to fix their macOS CI build which is failing

Hello, After fixing a build issue with mariadb, and hearing we have mariadb building on 10.7 to 10.15, the mariadb team are asking for some help getting their CI build on macOS working again. They are stuck, and worried about macOS support with no CI build working. Looks like a couple of

<    1   2   3   4   5   6   7   8   >