Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:28 PM, Herby G wrote: > > > so far, name-suffix is winning on all fronts...with no downsides yet. > > I don't plan on pushing the issue, but I have to say that I don't agree. > I originally suggested both, and got no purchase on either, so had to push one of them to

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:16 PM, Craig Treleaven wrote: > > > Personally, I don’t see any compelling reason why the MacPorts project should > want to go in this direction. The first paragraph on our homepage says: Actually, I’m perfectly happy with a blanket “NO” on all this, if that is the

Re: port "cask" -- installing prebuilt binaries

category-only identifier is less clear and less obvious harder to remember how to search for name conflicts with a non-binary version (eg for newer systems that can build it) so far, name-suffix is winning on all fronts...with no downsides yet. K

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 10:50 AM, Herby G wrote: > a "binary"/"binary_only" (or a new MacPorts specific name for these) as a > *category*, just as we have the "aqua" category > in this way, binary-only apps can continue to be represented in respected > categories with "binary" as their secondary

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 8:23 AM, Arno Hautala wrote: > >> On 6 Aug 2020, at 10:10, Ken Cunningham >> wrote: >> >> How about I float a suggestion? We could append "_binary" to the name. >> Otherwise leave the categories, notes, etc as they are n

Re: port "cask" -- installing prebuilt binaries

All valid points. I thought we had more-or-less got past the “should we” and moved on to the “how should we”, I am not necessarily championing this, but people are submitting these, and there is demand.here are nearly 4000 cask installer formulae on brew now. If similar binary-only ports are g

Re: port "cask" -- installing prebuilt binaries

How about I float a suggestion? We could append "_binary" to the name. Otherwise leave the categories, notes, etc as they are now. So a port that installs the Zoom teleconferencing application would be called "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to do thei

Re: port "cask" -- installing prebuilt binaries

> Sure, let's repeat this a few more times until everyone *really* got that. :-) That's exactly why the indicator should not be a variant. Variant indicates an option to install one way or the other, and a given port on a given system will not have such an option. K

Re: port "cask" -- installing prebuilt binaries

I wasn't imagining a variant for binary-only installs. If a port can be built, we should build it. But for things we can't build, (like Zoom or Microsoft Word) installing a binary is the only option and some ports of this type seem to be what people are submitting recently. This is fine -- som

Re: port "cask" -- installing prebuilt binaries

> >> From the user's perspective, how does that differ from a port that's > > available as a binary archive? I presume the idea is that it directly uses > > a precompiled binary from the upstream source, but from the user's > > perspective, does it really matter whether it was a binary from ups

port "cask" -- installing prebuilt binaries

there seems to be demand for replicating the “binary only” installers of homebrew cask. we have a few ports that do that now, and I see more and more coming in. I have used homebrew cask from time to time to see what it’s up to. It is convenient at times. I also downloaded a lot of things that

how to install and use a newer libc++ on older systems 10.7 to 10.12

You may have noticed that current software sometimes requires newer libc++ features than the installed system libc++.dylib version can support. The libcxx port has the capability to install a newer libc++.dylib, currently the libc++ that matches llvm-5.0, which is quite recent in terms of OS ver

Re: PRs now going back 18 months -- let's close the clearly dead ones

over hassle to close them when they are accidentally fixed by some commit. K > On Jul 25, 2020, at 23:20, Ryan Schmidt wrote: > > > >> On Jul 25, 2020, at 15:38, Ken Cunningham wrote: >> >> There are ancient PRs that are never going to be committed in the queu

PRs now going back 18 months -- let's close the clearly dead ones

There are ancient PRs that are never going to be committed in the queue. This is just noise, and prevents us from keeping things moving. The people who opened them seem attached to them, but they are clearly dead and need to be closed. If in agreement, can one of the admins close the 50 oldest

Re: Help with UsingTheRightCompiler

> build.args CC="${configure.cpp} [get_canonical_archflags cc]" Try this perhaps: build.args CC="${configure.cxx} [get_canonical_archflags cxx]" There are other methods some might prefer besides this. BTW, the software has this issue because the author threw a c++ include file into a

Re: Help with UsingTheRightCompiler

> You have to use clang++ if you are calling in c++ includes. > > Then it will work. Having read over the other comments, and in case that wan’t clear — if you use /usr/bin/clang++ your build will automatically find the c++ includes, and you don’t need to do any of those suggestions with -isysr

Re: Help with UsingTheRightCompiler

> Hi developers! > > > I’m trying to get the new Portfile ncplot to UseTheRightCompiler. It uses a > primitive Makefile but not a configure file. So I added the makefile 1.0 > portgroup. However, I get a build error when I do. Can anyone help? > > Error is: > > :info:build In file included fr

Re: Some questions regarding MacPorts legacy support package

> On Jul 5, 2020, at 3:03 PM, Jason Liu wrote: > > > Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there some > way of making it optional? It will have to be specifically disabled by default, and then turned out optionally with some new legacysupport toggle that I/we in

Re: clang, c++17, std::optional, and libc++.dylib

> > Then all systems from 10.5 to current can use c++17 std::optional, and > disaster averted until the next crisis. > The next crisis will likely be std::filesystem, and there is no inlining that, btw. K

Re: clang, c++17, std::optional, and libc++.dylib

> On Jul 5, 2020, at 03:13, Ryan Schmidt wrote: > >> On Jul 5, 2020, at 00:33, Ken Cunningham wrote: >> >> It is quite simple (I think) to inline a function implementing >> bad_optional_access into the header. That could be used for 10.7 >> to 10.

Re: clang, c++17, std::optional, and libc++.dylib

> > Chris > >> On 5 Jul 2020, at 6:33 am, Ken Cunningham >> wrote: >> >> As software using c++17 is upon us, we have a slight problem with >> std::optional. >> >> clang has supported std::optional for some time, and clang-9.0, at

clang, c++17, std::optional, and libc++.dylib

As software using c++17 is upon us, we have a slight problem with std::optional. clang has supported std::optional for some time, and clang-9.0, at least, appears to support std::optional right back to the ancient systems. however, there is one small part of std::optional, std::optional::value,

Re: several messages

oh, btw Fred, your impression of MAC_OS_X_VERSION_MAX_ALLOWED is not quite right. It doesn't indicate removed features. It indicates the SDK version you are currently building with, so you know what API you can use. This is always confusing, which is why we use what we do in legacysupport, in

Re: several messages

> several messages > > Fred Wright fw at fwright.net  > > Sun Jul 5 04:08:09 UTC 2020 > > Previous message (by thread): Some questions regarding MacP

Re: Some questions regarding MacPorts legacy support package

> Some questions regarding MacPorts legacy support package > > Jason Liu jasonliu at umich.edu  >

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 MacPort

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

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 ev

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 th

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

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, and

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

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 (bar

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

been the policy to this day. >> >> 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, a

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 som

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 c

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 your fav

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 t

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 in

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 pro

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 f

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 is

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

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 will

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 tha

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

doesn't seem to, no doubt to 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 l

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 s

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

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

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, e

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 ou

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

pecific port 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

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 Sc

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 w

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. > > https://github.com/macpo

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'

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 no

Re: gcc7/libgcc7 problems

Good 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

Re: gcc7/libgcc7 problems

working 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, K

Re: gcc7/libgcc7 problems

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

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 systems

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 thi

Re: error: thread-local storage is not supported

fficial-clang-supports/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

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 disable

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 necessari

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 clan

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 enviro

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 rem

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

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 please

Re: implementation of configure.env-append

ote: > On 2019-10-10 07: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... > &g

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 direct

Re: implementation of configure.env-append

of cruft in Portfiles 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 tri

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   >