Re: CI system for PR builds

I've taken some of them on, including the oldest one (From Ryan, of all people) for a game called enigma from a submission 10 years ago. I advise you to be very careful with them, based on the ones I've seen. Lots of them are not of high quality, build wrongly or against the wrong libraries,

gcc6, libgcc, and the ABI issue reprised

There is expressed concern about the improvements to portconfigure.tcl to put forth gcc6 for PPC instead of clang-3.4 (which always fails) when the default compilers were blacklisted. I don't see there being such a concern. I'd hope to put some of this to rest with a few examples. 1. the

Re: [macports-ports] branch master updated: nzbget: add cxx11 1.1 PG

On 2018-04-16, at 10:55 PM, Ryan Schmidt wrote: > > On Apr 17, 2018, at 00:43, Ken wrote: > >> Ken (kencu) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/8f64c49b083ab312882b2f7c3b45658a49a37397 >> >> The

Re: [macports-ports] branch master updated: gcc7 / libgcc: fix build on Intel Tiger

gt;> https://github.com/macports/macports-ports/commit/084e2e8809afc62472eafc9c098b4bc9249b48b0 >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new 084e2e8 gcc7 / libgcc: fix build on Intel Tiger >> >> 084e2e8 is described below >> >&g

Re: Binary packages not rebuilding against updated libraries

On 2018-04-24, at 9:05 AM, Artur Szostak wrote: > > So then there is a bug from what I understand, or cfitsio in MacPorts is > being built incorrectly. Compare file names for the newer Cfitsio: > /opt/local/lib/libcfitsio.6.3.44.dylib > /opt/local/lib/libcfitsio.6.dylib ->

Re: [macports-ports] branch master updated: collectd: update to 5.8.0

> On Apr 24, 2018, at 10:41 AM, Perry E. Metzger wrote: > >> I wouldn't consider version updates to be a minor change permitted >> by openmaintainer. All too often they are not in fact "simple". > > I do, in fact, consider it that way, and I need some way of telling >

Re: [macports-ports] 01/01: icu: update to 61.1

On 2018-04-23, at 9:46 AM, Leonardo Brondani Schenkel wrote: > On 2018-04-23 18:07, Ryan Schmidt wrote: >> I've been meaning to revisit updating icu, now that we have the cxx11 1.1 >> portgroup. Let me know what you discover! > > I meant to push this to a branch on my fork, ended up pushing to

disable-dependency-tracking issue all of a sudden?

Several gnome ports seem to be failing to update with a similar error all of a sudden: config.status: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. Try re-running configure with the '--disable-dependency-tracking' option to at least

Re: [macports-ports] branch master updated: gcc7 / libgcc: fix build on Intel Tiger

On 2018-04-16, at 4:29 PM, Ryan Schmidt wrote: > > > Do these ports build for you on PowerPC Tiger? They didn't for me, last time > I checked a month or two ago. Yes, both gcc6 / libgcc6 and gcc7 / libgcc7 build fine without these patches on PPC Tiger. I haven't had any troubles with any of

Re: Agility

On 2018-04-25, at 9:23 AM, Chris Jones wrote: > >> I have one request though. You are sometimes asking people to close >> the PRs because you don't want unfinished PRs in the queue. I would >> like to suggest adding a special label to such PRs before closing >> them, saying something like

Re: What "openmaintainer" means

On 2018-04-25, at 10:13 AM, Mojca Miklavec wrote: > And if there's a need, we could of course define more levels of "how > closed" a port should be. This is another case where for a lot of > software updates are usually trivial, while for others it may break > your system (say, when software

Re: Blacklisting gcc

On 2018-03-27, at 7:43 AM, Benjamin Redelings wrote: > I suppose there could be a c++14 portgroup? There could be. But I would instead propose that MacPorts never puts forward a compiler that can't handle c++14 at this point in time instead. If the system-installed clang is new enough to

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 10:04 AM, René J.V. Bertin wrote: > > I'm not sure I follow nor that I agree with what I think I understand. If > pegged ports are ports no longer supported (in that form/version) on the main > tree, why would they have to follow what the main tree does with their > current

Re: Blacklisting gcc

I think blacklisting *gcc-4* would achieve the desired goal. gcc-3.x is no longer a compiler macports puts forward for use, so can be ignored now. K > On Mar 26, 2018, at 01:25, Mojca Miklavec wrote: > >> On 26 March 2018 at 02:49, Ryan Schmidt wrote: >>> On Mar 25, 2018,

Re: how to handle this element in Makefile.config ?

On 2018-03-26, at 11:03 AM, macpo...@parvis.nl wrote: >> Try setting the variable in build.args instead: >> >> build.args-append JCVALID=no >> >> Rainer > > no effect sounds like patches are your friend, then, if you can't override it with settings. K

Re: xcodebuild wants to write to $HOME/Library/Developer (was: Re: Editing Git history with GitUp)

You might check the two mulle* ports I added last year. One lets you dump all the settings in a project, the other lets you set them on the fly in a portfile. K Sent from my iPhone > On Apr 2, 2018, at 10:11 AM, Rainer Müller wrote: > >> On 2018-03-23 11:17, Mojca

Re: xcodebuild wants to write to $HOME/Library/Developer (was: Re: Editing Git history with GitUp)

There's a third mulle* port that converts xcode projects into cmake projects that I have used as well. Sent from my iPhone > On Apr 2, 2018, at 10:11 AM, Rainer Müller wrote: > >> On 2018-03-23 11:17, Mojca Miklavec wrote: >> I just stumbled upon this app (I haven't

Re: Port trees for specific versions of MacOS

> On Mar 31, 2018, at 8:08 AM, Mojca Miklavec wrote: > A few problems I see with this approach: > (a) What happens when a dependency of one of those ports is changed. > Unless you have some CI system in place for this to tell you that a > port needs a revbump at least, you

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 9:20 AM, René J.V. Bertin wrote: > On Wednesday March 28 2018 09:00:52 Ken Cunningham wrote: > > Thanks for picking this up, > >> I'd just like to mention that I've been working on this on my own for a >> while now, and have such trees

Re: Request for assistance closing some old pull requests

> > There's no good way to shim the ABI without having something > physically deal with this problem, which likely requires a lot of > work on very low level hacking. When last I read about this, the Wine devs were asking for compiler support in clang to accomplish this feat. I bet they will

Re: [macports-ports] branch master updated: libcaer: new port

> On Mar 1, 2018, at 11:23 AM, Perry E. Metzger wrote: > > Looking over things carefully seems reasonable. A machine can't > figure out that a Portfile should be written differently. > > Having to build locally in several ways seems bad. The purpose of > automatic CI

Re: #55884: mandoc @1.14.3: not using the right compiler

On 2018-03-03, at 1:14 PM, Jan Stary wrote: > > What of I have two of those, with different Xcode on each? That is undesirable for reproducible builds. Most users have the default Xcode version for a give system, as Apple flushes all the updates that way. If users report broken builds and

Re: Upgrading Pandoc

Upgrading haskell looks to be super complicated. Best bet is to work with Clement on it if you have skills for that. Otherwise wait until he has time. Best, K Sent from my iPhone > On Mar 4, 2018, at 11:18 AM, Mark Anderson wrote: > > So I started trying to move pandoc from

Re: [MacPorts] #50645: lapack 3.6.0 update from svn instead of the tarball

Looks like the latest released version is 3.8.0 now. http://www.netlib.org/lapack/lapack-3.8.0.tar.gz So the port could be due for an update to that version. Ken On 2018-03-02, at 4:31 PM, G A wrote: > This is an old report. But thats ok I have my own repo of macports with > updated and

Re: buildbot (10.5-10.8) SSL/TLS issues

The only solution at present is a custom build of macports against a new libcurl. Just ignore these failures until distfile mirroring gets fixed. Ken Sent from my iPhone > On Mar 2, 2018, at 4:16 PM, Helmut K. C. Tessarek > wrote: > > I've received a few errors from

Re: [macports-ports] branch master updated: libcaer: new port

CI is not sufficient testing to commit, sadly. There is no xcode 9 in travis at present. misses many things, like liscence etc doesn't check if destrooting is right It's OK for a minor version update of an existing port, but all new ports or sig updates need to checked out locally, port lint

Re: Agility

On 2018-04-25, at 11:02 AM, Chris Jones wrote: > > That, frankly, would be absurb. > > Chris Absurd might be strong. It depends on the stage of your work. A nearly completed patch that needs a few tweaks is one thing. A PR list full of [WIP] PRs that have gone nowhere for six or twelve

Re: How do I check what is autobuilding successfully?

On 2018-04-25, at 11:58 AM, Perry E. Metzger wrote: > There's a port I suspect hasn't built in a long while. How can I > check on what is and isn't building on the buildbots? > > -- > Perry E. Metzger pmetz...@macports.org check packages.macports.org and see if it's there and if

Re: Keep 32-bit build support on Mojave

On 2018-10-01, at 3:50 PM, Joshua Root wrote: > On 2018-9-24 18:22 , Ryan Schmidt wrote: >> https://github.com/ryandesign/macports-base/commits/MacOSX.sdk > > Second, I'm not sure about changing the SDK only some of the time, or > not changing the deployment target. > I'm not sure how much

thread_local storage on 10.6.8 with clang-7.0

With a couple of very minor modifications, recent versions of clang will support thread_local storage including support for complex destructors on 10.6.8 using the same emutls.c system that gcc uses to support it. I'll attach the (amazingly simple) patches below. It picks up the emutls.c

Re: Commit History vs User Convenience

On 2018-10-08, at 9:31 AM, Chris Jones wrote: > > To be honest, my concern with the above is to get adequate testing, across a > range of macOS versions, rather than nuances around the revisions... So lets > focus energies on that aspect... > > Chris Ah, the lure of the bikeshedding is

tenfourfox - should it be in the MacPorts repo?

Older MacOS versions lack browsers that support TLSv1.2, and other enhancements that allow them to work comfortably in the current world. Cameron Kaiser has been dutifully maintaining a fork of Firefox for a decade that works nicely on PPC Macs 10.4 and 10.5, and keeps it remarkably up to date

Re: tenfourfox - should it be in the MacPorts repo?

On 2018-10-11, at 10:05 AM, Christopher Jones wrote: > Hi, > > Being ’niche’ in itself is no reason to not include something in MacPorts, so > that shouldn’t be a concern. We have plenty of ‘niche’ ports already, which > is partly what makes MacPorts better than the alternatives ;) > > If

Re: tenfourfox - should it be in the MacPorts repo?

On 2018-10-11, at 10:38 AM, Christopher Jones wrote: > Hi, > > A couple other thoughts… > > What platforms do you see this being useful on ? I know that older platforms, > but newer than 10.4, also have issues with SSL/TLS support. Presumably this > would also be useful on these ? 10.6 ?

Re: Merging pull requests before 72 hours

On 2018-10-18, at 1:18 PM, Christopher Jones wrote: > > Beyond the above, not really. If it is indeed agreed that some package > version updates are allowed under the ‘minor’ tag, then I think the best you > can do is just state that, and acknowledge that the determination of what is > or is

icu 63.1 build errors

As we’re pondering the PR to update ICU to what amounts to a new ABI version, and as github is hosed tonight, I thought I would point people to freebsd’s attack on this issue when they braced ICU 61 and the failures they saw in doing so.

Re: Merging pull requests before 72 hours

> On Oct 21, 2018, at 10:46 AM, Mojca Miklavec wrote: > > > They currently have 28 issues open for formulas. We have ... > thousands? (Last time I checked it was somewhere between 4k and 5k.) > Disclaimer: I don't know what their policy on closing the issues is. There is a “Stale Bot” that

icu is old

I have another port that I can't update due to a too-old icu (mozjs60). I think we're going to have to find some way to update icu. If we need a non-c++11 version, I guess we'll have to make that as a separate port perhaps. Ken

Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13

On 2018-10-23, at 8:18 AM, Chris Jones wrote: > >> We have worked around this in a number of ports so far, and turned off some >> functionality in others. >> I use the_silver_searcher to find stuff like this, for example in the >> macports-ports repo: >> ag -i clock_gettime . > > Sorry, I

Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13

On 2018-10-23, at 1:57 AM, Chris Jones wrote: > Hi, > > I've stumbled into the same issue twice in recent days, with two different > ports, which is the use of > > clock_gettime(CLOCK_REALTIME, ); > > which is only available in macOS 10.12 or newer. See for instance the issue I > found

Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13

Yep, that is exactly what I was thinking as well. I was pondering a specific include folder like ${prefix}/include/snowleopardfixes for want of a better title for it, where these could be placed. Then we could just add that folder to the beginning of the system header search queue. (It would

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

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

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 t

Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13

On 2018-10-23, at 4:23 PM, Chris Jones wrote: > > I see no reason to not just place them directly in the main MacPorts include > prefix, i.e. normally /opt/local/include. Placing them anywhere else requires > that specific folder to be included as well, which is a complication I dont > see

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

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

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

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:

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

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

, 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 actually bu

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

Re: mojave 32-bit compatible and universal builds

agine > 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 Nov 4, 2018, at 01

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

Re: new xcode build system and build failures

> On Oct 1, 2018, at 1:00 PM, Rainer Müller wrote: > > > One of the bugs with most impact seems to be that it always uses the > user home from Directory Service and does not respect $HOME in the > environment. The build system want to place > ~/Library/Developer/Xcode/DerivedData/ there, but

Re: new xcode build system and build failures

On 2018-10-01, at 7:00 AM, Ken Cunningham wrote: > To force Xcode10 to use the old build system (as it did before) Pre-coffee correction. Xcode 10 always defaulted to the new build system. Previous Xcode versions used the old build system by default.

new xcode build system and build failures

Xcode 9 introduced a new build system behind the scenes, but it was not the default, so most of us building OSS didn't really notice. Xcode10 has made it the default, and now a number of errors are showing

Error: Unable to determine location of a macOS SDK.

Brand new installation of High Sierra, installed Xcode from App Store, opened it, installed MacPorts from installer. Then: $ sudo port selfupdate ---> Updating MacPorts base sources using rsync MacPorts base version 2.5.4 installed, MacPorts base version 2.5.4 downloaded. ---> Updating the

Re: Error: Unable to determine location of a macOS SDK.

> On Oct 6, 2018, at 5:24 PM, Joshua Root wrote: > > This is one of the reasons our installation instructions say to install > both Xcode and the Command Line Tools. But see also > . > > - Josh Exactly. I will admit I am currently trying (myself) to

Re: new xcode build system and build failures

On 2018-10-01, at 7:53 AM, Ryan Schmidt wrote: > > > On Oct 1, 2018, at 09:00, Ken Cunningham wrote: > >> To force Xcode10 to use the old build system (as it did before) add this >> flag to the xcodebuild args. Some ports need this in both the build and >> de

re:ranlib: malformed objects on 10.6

> After upgrading ports on 10.6 (I probably didn't touch the machine since > about May this year) I ran into issue compiling software with clang-5.0 > against libc++: /usr/bin/ranlib: object: .libs/libfoo.a(libfoo_la-bar-file.o) malformed object (unknown load command 2) ar: internal ranlib

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 3:02 PM, Ken Cunningham > wrote: > > > >> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: >> Yes, but based on the above output, the SDK wasn't used. If the SDK had been >> used, a 32-bit build would not have been possible, as far

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: > >> So — something is still working right, at least on 10.13 with Xcode 10. > > Yes, but based on the above output, the SDK wasn't used. If the SDK had been > used, a 32-bit build would not have been possible, as far as I understand. >

Re: final buildbot setup for high sierra?

> On Sep 20, 2018, at 2:07 PM, Ryan Schmidt wrote: > Yes, but based on the above output, the SDK wasn't used. If the SDK had been > used, a 32-bit build would not have been possible, as far as I understand. > You are right, the SDK apparently has no tapi symbols for i386: configure:3118:

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

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

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

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

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

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

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

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

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

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.

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

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

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 having emu

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

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

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

final buildbot setup for high sierra?

I’m about to archive my current high sierra setup into a VM, and if possible, I’d like it to match the way the buildbot will be finally left. 10.13 with XCode 9? or 10.13 with Xcode 10? I guess people who stay on 10.13 will be prompted to upgrade to XCode 10 by the App Store, and so I

Re: viewing code while respecting defines

Thank you, Perry! I see it’s right there in Xcode — I just never noticed it before. That (at present) is likely about as close as I will get to what I want. Ken > On Sep 18, 2018, at 5:11 AM, Perry E. Metzger wrote: > > On Mon, 10 Sep 2018 12:15:37 -0700 Michael > wrote: >> Is there a way

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

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

, 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 again. &g

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, are ac

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

Re: Buildbot failures on 10.11

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

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: 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: OSX 10.6 clang / llvm circular dependency

urrent 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, maybe me, forgo

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

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

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

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

> 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

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

<    1   2   3   4   5   6   7   8   >