Re: our "sudo port install gnome" metaport is not working -- GNOME needs help

Yeah -- maybe pointless. Dave is going over other things instead, and I'm sure he'll get to whatever it is in due course of time. "sudo port install gnome" is broken, but no doubt that'll be fixed in time. K

Re: our "sudo port install gnome" metaport is not working -- GNOME needs help

On 2020-07-01, at 11:21 PM, Ryan Schmidt wrote: > Is this build failure with some modifications you've made to these ports? I'll start with the most important bit -- I think the gnome metaport is a flagship port for Macports, and it won't install. I recommended it today to some new

our "sudo port install gnome" metaport is not working -- GNOME needs help

this I think “sudo port install gnome" is a popular metaport, but it’s presently broken initially polari won’t build, but that’s because gjs won’t build, but that’s because we don’t have mozjs68 … and then who knows... I wonder if interested people might dive in and give Dave a hand — GNOME is

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> On Jun 23, 2020, at 12:48 AM, Ryan Schmidt wrote: > > My ports are slightly out of date but I don't see a choking amount of > dependencies for curl on High Sierra: > > $ port rdeps curl > The following ports are dependencies of curl @7.70.0_0+ssl: > xz >lbzip2 >libiconv >

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

On 2020-06-27, at 6:27 AM, Daniel J. Luke wrote: > On Jun 22, 2020, at 11:20 PM, Ryan Schmidt wrote: >> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote: >>> We should just have one perl5 port that tracks the current release. >> >> You say this every year (or at least often). > > I say this

Re: macos as vm guest

> after my development mac mini died (and the time backup appeared to be > corrupt) i had to buy another mac. > now i have a 2013 imac that can run catalina, but sometimes i also need 10.11 > for older hardware and software, and 10.13 for compatibilty with our other > macs. > > i would like

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> On Jun 23, 2020, at 00:48, Ryan Schmidt wrote: > > You yourself have suggested multiple times that we should move more towards > always using MacPorts compilers on older systems even for ports that don't > require it because it's less easier for the maintainer to be able to assume a >

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

On Jun 23, 2020, at 00:48, Ryan Schmidt wrote: >> Feel free to set the bar, if you care to. And hopefully, don’t move it too >> often…IMHO. > > I'm not sure what you mean. Exactly what I stated with... If MP would pick one perl and one python that everyone is meant to use, declare it,

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote: > > I can't corroborate that claim, but of course we are interested in reducing > bloat in MacPorts and welcome any suggestions or improvements toward that end. I’m surprised — that has always been near point #1 on every homebrew vs.

randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

A simple used-to-be-quick build of "curl" now requires two different perls installed. Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat. It might be an idea for the admins to "set" the perl version all ports will use

Re: Call for designers for our ports website

sorry —we’re 835 openssl installs. wrong drop-down. K > On Jun 13, 2020, at 8:56 AM, Ken Cunningham > wrote: > > No doubt it caused some tempest. > > I was wrong, homebrew’s published stats say they have 5 million openssl > installs this year <https://formulae.brew.s

Re: Call for designers for our ports website

t;> >> Personally, I would be fairly disappointed if MacPorts went opt-in as such >> policies suffer from statistical issues in addition to the obvious >> privacy-related ones. >> >> Saagar Jha >> >>> On Jun 12, 2020, at 16:48, Ken

Re: Call for designers for our ports website

> On Jun 12, 2020, at 6:03 PM, Saagar Jha wrote: > > I believe the lack of change there is almost certainly a matter of the > project’s personal stance rather than “nobody having a problem with it”. "sufficient to make them change that policy" > Personally, I would be fairly disappointed if

Re: Call for designers for our ports website

Just FYI Homebrew has always been opt-out for stats. Nobody seems to have a problem with that sufficient to make them change that policy. We'll never know if that is why they seem to have 10 x the users on their stats page. K

polly as default on llvm...

does any one have any insight into why polly has always been a non-default variant of our llvm? It is a routine add on for all the llvm builds elsewhere, builds broadly, and I was going to just wrap it in and delete the variant, or at least make it a default variant, unless there's a reason

Re: Need some advice regarding patches for old AppKit compatibility

> does that sentence mean that the MacPorts legacy support package itself needs > GNU make, or does it mean that any portfile that uses the legacysupport > PortGroup needs to add GNU make as a build dependency? That line, and a lot of the other stuff added recently to the front page, is quite

Re: upgrading self-built MacPorts and version management

I started a page about installing MacPorts on Ubuntu, if you have any contributions to suggest. I actually do use this for simple things at present. https://trac.macports.org/wiki/InstallingMacPortsOnUbuntuLinux K

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

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

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

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

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

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

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

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

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

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

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

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

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,

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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,

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

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

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

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: scope of configure.optflags, configure.compiler etc. command line variables

-Wl,-no_pie Is the linker option you were looking for. 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: 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: 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: > 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: 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

<    1   2   3   4   5   6   7   8   >