Re: loading checksums table from pre-checksum block?

On 2018-10-27, at 3:52 PM, Ryan Schmidt wrote: > > > On Oct 27, 2018, at 17:37, René J.V. Bertin wrote: > >> No, I do not want to reintegrate the 60-some checksums into the portfile, I >> don't want to split it up and I don't want to rewrite my checksum generator >> script either. My questi

forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

I notice homebrew is forcing the installation of binaries built on their 10.12 or 10.13 builders onto 10.14 to get around the 32bit build problem on 10.14. I don't believe there is any way to force our binary installer to install older system builds in the same way -- but if there was, it would

mojave 32-bit compatible and universal builds

I thought I’d try a 32-bit compatible installation of MacPorts today on Mojave as a proof-of-concept, so I made a new prefix under /opt/universal and set up macports in it. I installed a copy of the MacOSX10.13.sdk and referenced that during the builds. To make it work, I made a couple of mi

Re: mojave 32-bit compatible and universal builds

, which I have to imagine > will eventually. > > —Mark > ___ > Mark E. Anderson > > >> On Sun, Nov 4, 2018 at 9:44 AM Christopher Jones >> wrote: >> >> >> > On 4 Nov 2018, at 1:54 pm, Ryan Schmidt wrote: >> > >> > On N

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 6:44 AM, Christopher Jones > wrote: > I don’t get all the effort going into keep 32 bit going for just a little bit > longer, until Apple completely pull the plug, in a future macOS release. > > Chris > It’s because there are a few packages, like wine and some of the e

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 5:54 AM, Ryan Schmidt wrote: > I thought we decided we didn't want to pursue that idea, based on Joshua's > objections, and instead we wanted to figure out a way to compile universal > with the 10.14 SDK, maybe by making a universal 10.14 SDK, That’s why I thought I’d ac

Re: mojave 32-bit compatible and universal builds

> On Nov 4, 2018, at 9:07 AM, Ken Cunningham > wrote: > > In the end, the thing that *does* work is to set the -isysroot to > /path/to/MacOSX10.14.sdk and the -syslibroot to / now why would I make that typo? Need another coffee this am I guess. In the end, the thing that *d

Re: mojave 32-bit compatible and universal builds

I think I have this clean enough to present for the curious…here are the (minor) tweaks. put the MacOSX10.13.sdk in the proper location in your active Xcode.app put this in macports.conf macosx_deployment_target 10.13 macosx_sdk_version 10.13 and in portconfigure.tcl change l

portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

I noticed this recently "fixing" some ports that don't use a configure step. During the run of portconfigure.tcl, various things (sdkroot) might be tested, and the appropriate values appended to the ENV variables. But these things don't seem to come out in the configure.variables, like I would

Re: portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

> On Nov 6, 2018, at 1:54 PM, Ryan Schmidt wrote: > > > > On Nov 6, 2018, at 14:48, Ken Cunningham wrote: > >> I noticed this recently "fixing" some ports that don't use a configure step. >> >> During the run of portconfigure.tcl, va

Re: portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

On 2018-11-07, at 1:27 PM, Ryan Schmidt wrote: Thanks for the detailed explanation. I do understand what you mean about +universal. Just to point out that this port is not actually building universal here, it's just building normally. What I was expecting would be that portconfigure.tcl would

Re: portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

hanks, Ken > On Nov 8, 2018, at 04:38, Ryan Schmidt wrote: > > > >> On Nov 7, 2018, at 17:28, Ken Cunningham wrote: >> >> Thanks for the detailed explanation. I do understand what you mean about >> +universal. Just to point out that this port is not actual

Re: portconfigure.tcl - why does appending to an ENV variable (like CFLAGS) not also append to configure.cflags ?

On 2018-11-08, at 8:16 AM, Ken Cunningham wrote: > OK. I guess the answer to my question then really is that it is apparently > purposelful and desired behavoir that > > configure.cxxflags is not set up the same as CXXFLAGS > > and likewise for all the others as well. Tha

Re: Seeming flaw in Xcode 10

> > On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger > wrote: > As some of you are aware, XCode 10 no longer searches SDK include > directories for C headers specified with " marks, as in > And vice-versa — it will no longer search the source path for any files spec

Re: Seeming flaw in Xcode 10

> On Nov 11, 2018, at 3:07 PM, Perry E. Metzger wrote: > > No, that works if is in the system includes path, and > that's standards conformant. What I know about this, no doubt incomplete, comes from here: https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_not

Re: Xcode configuration woes

clock_gettime is one of the functions elegantly replaced by the legacy Portgroup, FYI... K > On Nov 22, 2018, at 02:39, Vincent Habchi wrote: > > Ryan, > >> It failed to build on the 10.11 and older buildbot workers not because of >> qgis3 but because of its dependency postgresql10: >> >> h

Re: altivec compiler

all the standard MacPorts compilers (gcc versions, clang versions) support the -faltivec flag. This flag is only useful on PowerPC systems, which I would be surprised if you were targeting. Is that the system you're after? The fact that it's still in the config suggests this is a very old piece

Re: altivec compiler

and lapack? Arpack is currently installed on my system with variants > +accelerate +gfortran +mpich only. > > Mark Brethen > mark.bret...@gmail.com > > > >> On Nov 23, 2018, at 11:19 AM, Ken Cunningham >> wrote: >> >> all the standard MacPorts co

gimp-print -- was Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

On 2018-11-30, at 1:30 PM, MacPorts wrote: > > Comment (by mouse07410): > > Clang of Xcode-10.1 does not accept {{{-syslibroot}}} argument at all. > That's what prevents {{gimp-print}}} from being built on Mojave: > Mouse, I don't think it's Xcode 10; rather that libtool in gimp-print is very

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

libc++abi.dylib. It's a tiny bit tricky, and might well need to be manual steps. You have to build clang-5.0 first with thread support enabled as below, and then use that to build the new libc++abi.dylib. And once that new libc++abi.dylib is installed, everything works. Ken On 2018

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

and how that is supposed to be useful if the symbols are hidden. How can you use them? Ken On 2018-12-07, at 11:29 AM, Ken Cunningham wrote: > > > As per the details in the previous post below that I sent a few weeks ago, I > have clang/llvm thread_local support working n

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

> At present I don't seem to know enough about the underpinnings to see how to > change the visibility settings on the emutls objects from libclang_rt when > placed into the executable. I think I'm possibly getting my head around this... ___emutls_get_address is not hidden in libclang_rt, it'

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

On 2018-12-08, at 10:24 AM, Ken Cunningham wrote: > >> At present I don't seem to know enough about the underpinnings to see how to >> change the visibility settings on the emutls objects from libclang_rt when >> placed into the executable. > So perhaps havin

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

On 2018-12-09, at 9:50 PM, Jeremy Sequoia wrote: > > > Yuck. Sounds like typical bootstrapping hell :/. Maybe make +emutls a > variant on libcxxabi. Thanks! - in fact I did exactly that. Also sorted out building libcxx with newer compilers. I presently have libcxx 7.0.0 with emulated-tls ru

Re: thread_local storage on 10.6.8 (and earlier) with clang-7.0

Some more detailed / better answers to your raised issues: On 2018-12-09, at 9:50 PM, Jeremy Sequoia wrote: >> The issue is the "___emutls_get_address" function, which is called from >> libc++abi.dylib, and is built into clang_rt: >> >> $ nm >> /opt/local/libexec/llvm-5.0/lib/clang/5.0.1/lib

changes to clang-5.0

After lots of discussion with Jeremy and considerable testing, a few changes have been made to the core compiler, starting with clang-5.0 and then planning to add the same to newer versions, that you may or may not notice. The distilled version is that clang-5.0 will now support __thread and th

leave revision 0 line in Portfile

I would like to propose we stop asking people to remove the "revision 0" line in Portfiles. Rationale: Functionally the same either way. Insignificant size. it's properly located already. This takes thoght, why waste it for next time? It's petty and bikesheddy to ask everyone to remove it. Send

Re: python run depency

On 2018-12-22, at 10:15 PM, Mark Brethen wrote: > If a port installs a python script executable, is it necessary to have a run > dependency for python? > Ideally you would determine which python version(s) work with that software specify one current version then force the scripts to use th

Re: New project member: mark

Well done! Ken > On Dec 28, 2018, at 08:53, Rainer Müller wrote: > > Please join us in welcoming the following new MacPorts project member: > > - Mark Anderson (mark@, @markemer) > > We look forward to continued excellent contributions from these new team > members. > > - Joshua, Ryan, and R

bikeshedding the older systems...

Hi all, I am going to ask here for permission to go ahead and make adjustments to any ports that need fixing for os versions < 10.9 without the need for PRs or further discussions. Although I know there can always be several different ways of doing something, I tend to use these older systems

Re: Help with a Portfile

It is rather difficult to install libcurl with all it’s dependencies and certificates and keep it up to date with current security outside of Macports. I suggest you use the method outlined in the referenced ticket

should we change the default universal_archs now?

On all systems 10.6+ , universal_arches ="i386 x86_64" . That is pretty much what port authors expect to see these days, and except on 10.14, our compilers handle that OK. But on < 10.6, universal_arches="i386 ppc" This is a problem now, because our newer c++11 capable compilers can't cross c

Error writing data to TLS socket: The specified session has been invalidated for some reason.

I’m not sure which port is causing this error I’m seeing since recent updates. To see it, use something like epiphany or surf surf www.github.com epiphany www.github.com I think the error is in gnutls, maybe in libidn2? I’m narrowing it down to perhaps the srp authentication module, but I’m ou

Re: Error writing data to TLS socket: The specified session has been invalidated for some reason.

t; > Marius > -- > Marius Schamschula > > > > >> On Jan 18, 2019, at 6:08 PM, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> I’m not sure which port is causing this error I’m seeing since recent >> updates. >

Re: Issues with compiler flags in gfortran

On 2019-01-21, at 9:22 PM, Joshua Root wrote: > On 2019-1-22 01:47 , Nicolas Pavillon wrote: >> I then tried with another gfortran compiler outside of macports, and it >> could compile without any issue if I remove macports’ prefix from the >> path, which seems to indicate that the issue is comi

Re: Issues with compiler flags in gfortran

On 2019-01-21, at 10:08 PM, Ken Cunningham wrote: > $ xcrun -find as > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as > > $ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as > -v > Appl

Re: Issues with compiler flags in gfortran

So this "as" issue comes up with gcc / gfortran every so often, more lately with more attempts to use newer SIMD instruction sets that generate assembly that only newer clangs can assemble. There are scattered tickets here and there about it over the past few years. One partial but very practi

Re: Issues with compiler flags in gfortran

On 2019-01-22, at 2:37 AM, Joshua Root wrote: > > I think this issue overall is covered by > , and I agree with jeremyhu's > assessment there. > > - Josh Yes, we discussed it there similarly to this email chain. But Jeremy's solution five years ago w

Re: Issues with compiler flags in gfortran

> On Jan 23, 2019, at 00:06, Joshua Root wrote: > > '--with-as=${prefix}/bin/llvm-as-mp-7.0' 1. have to be sure we're not talking about the assembler for llvm IR here, which is a totally different thing...I think we call clang. 2. bootstrapping. the stock toolchain on many systems can't bui

function wrapping mechanism

Hi all, I’m about to commit a new type of system to macports-legacy-support, to “wrap” current library functions to enable updating them to current functionality. The general method is to: #define function function_original #include_next #undef function #define function macports_wrapped_f

Re: Error writing data to TLS socket: The specified session has been invalidated for some reason.

nutls, so perhaps that's a way out until this gets sorted: --disable-srp-authentication Ken On 2019-01-18, at 7:33 PM, Ken Cunningham wrote: > when I downgraded to gnutls 3.5.x (which required rolling back to the last > libidn2 due to a minor abi change) surf and epiphany both worked

Re: rpath argument change in GCC / LD

My understanding is that this should not work: -Wl,-rpath=“DIR” But these two are functionally the same, assuming they are not reordered. -Wl,-rpath -Wl,”DIR” or -Wl,-rpath,”DIR” Both are sent to the linker as two options sequentially: -rpath “DIR” Ken

Re: rpath argument change in GCC / LD

testing on my older OSX > boxes to see what happens there, since I'm guessing they use MP's linker (as > Xcode's is so old). If (3) works on all of the linkers, then I'll go with it > (patching to include the ""s). - MLD > > On Mon, Feb 4, 2019,

Re: rpath argument change in GCC / LD

> If the port is using the as version from cctools Hey, Chris — all that applies to the assembler, but Michael is trying to beat the linker into submission. K

Re: OSX 10.6 clang / llvm circular dependency

Someone, maybe me, forgot to blacklist clang 7.0 when building clang 7.0. It's a 10 second fix in the portfile; I'll take care of it in a few minutes. Thanks for noticing. Ken

Re: OSX 10.6 clang / llvm circular dependency

list the current compiler. Ken On 2019-02-11, at 8:47 AM, Michael Dickens wrote: > awesome! looking forward to having this issue behind me! I'll check out your > changes this afternoon ... - MLD > > On Mon, Feb 11, 2019, at 11:37 AM, Ken Cunningham wrote: >> Someone,

introduce @lastic

Hello all, I thought I would take a moment to introduce a new port maintainer recruited from the macrumors forums, @lastic (Erik). Erik originally found and started building and distributing the “smtube” software port I brought in recently, and comes on as a co-maintainer of that port to begin

Re: compilers that support thread-local storage?

__thread came first, then thread_local a bit later. the difference is that thread_local allows more complicated initializers and destructors ("non-trivial"). It is c++11, as you said. quite old gcc versions support __thread I think the earliest one was gcc 4.1

Re: compilers that support thread-local storage?

On 2019-02-13, at 10:23 AM, Ken Cunningham wrote: > For Xcode clang, you already have that -- 900+ You already had the more accurate Xcode clang version -- 900 is not right, it's the one you said. K

Re: Buildbot failures on 10.11

see also https://lists.macports.org/pipermail/macports-tickets/2019-March/255897.html ? delete the cache file? K

Can I trick base into installing ports that are built against libc++ on systems configured to stdlib=libc++ ?

I doubt this is possible, but it strikes me that a number of big ports, like clang-8.0, are actually forced in the portfile to build against libc++. And my 10.6.8 system is configured to use stdlib=libc++. But base can't rationalize this due to I suppose lack of any data showing this is how thi

Re: Can I trick base into installing ports that are built against libc++ on systems configured to stdlib=libc++ ?

archive site that has no issues when it runs through the rev-upgrade link check stage. So -- that's kinda useful for me, I think. Ken On 2019-03-31, at 9:34 PM, Ken Cunningham wrote: > I doubt this is possible, but it strikes me that a number of big ports, like > clang-8.0, a

xcode builds, Xcode 10, and fixing the xcode PG

Hello all, As you know, a number of MacPorts' xcode builds have been broken by the new xcode build system that came with Xcode 10. Maybe all of them, not sure. There are several underlying causes for this, I believe . I have been fixing these

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 VBo

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

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

ory in master) 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 feature

Re: Preparing for 2.6.0 beta - change universal defaults on 10.5 and less?

10.4 and 10.5 can’t cross-compile cxx11+, so I change the universal defaults on my systems to arch-specific. Perhaps this might be a good time to do it the same for everyone? Also, 10.5 intel might best be treated like 10.6 than like ppc... Ken Sent from my iPhone Sent from my iPhone

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

that error may be connected to this https://reviews.llvm.org/D57188 I don't know if anyone ever tried to build llvm/clang 7.0 using 8.0 before :> for now, try forcing the build with clang-5.0 or clang-3.7 while we see what comes of this. Should be a ticket if reproducible. K

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

The new ghc infrastructure is broken on 10.6, and at a quick glance, it looks like it starts building at 10.8, which is actually not too bad, and better than I thought: I am not sure if i will ever get around to trying to fix the older systems, and

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

10.6.8 i386 buildbot offline

just a heads-up that this buildbot appears to have been offline a couple of days now 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? Ken

Re: make mpstats a depends run on legacysupport?

I kind of expected that response :) How about a message in the legacysupport notes field at least, encouraging users to install mpstats if they want older systems support to be ongoing? I'd be willing to tolerate some statistical imperfections to get some better numbers about how to spend my t

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

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 mi

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 t

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

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

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 gene

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 ha

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

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

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 at

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 t

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

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 s

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 k

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, it'

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?

01:14, Chris 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: Xcode 11 & SDKROOT on macOS 10.14

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

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

Re: 2.6.0 features

that is extremely sensible and what many might expect, so we should consider adding it like that as a synonym for the compiler year, but that does also set that flag. I also said as much when this first came about. Many years ago I read that Apple (Steve) sat in a room watching people try to us

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

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 tic

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

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: removal of cxx11 PG and pre-snowleopard systems having some issues

> On Oct 6, 2019, at 7:28 PM, Joshua Root wrote: > > OK, that's certainly not expected behaviour, but it's nothing to do with > cxx11. > > - Josh Well, the ports that still have the cxx11 1.1 PG on them fall back properly to gcc-6, so from that point of view, they still work. Of course, t

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 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.

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 an

<    1   2   3   4   5   6   7   8   >