Re: llvm / clang / cctools / ld64 version consistency question

PM, Mihai Moldovan wrote: > On 27.07.2016 03:22 PM, Ken Cunningham wrote: >> Having run into an unexpected problem with clang-3.7 segfaulting not long ago >> after a 3.7 minor version update, and then an interesting libLTO incorrect >> "version error" when I tried

Re: Determine before installation whether a port can be installed

OK -- So - I am absolutely nobody at all on this list, so please take this following idea gently. This work you're embarking on (specifying what systems a given port will build on, and which it won't) would seem in fact to be very similar to what I was getting at when I asked about the

llvm / clang / cctools / ld64 version consistency question

Dear smart people, Having run into an unexpected problem with clang-3.7 segfaulting not long ago after a 3.7 minor version update, and then an interesting libLTO incorrect "version error" when I tried to upgrade the compiler chain from clang-3.7 to clang-3.8, I'd like to have a slightly better

Re: libcxx on older systems (eg 10.6) test and fixes format

Oh - crap. I just realized that MINOR is a qt4-mac specific global, not a Macports global. And it seemed so handy for what I wanted to do. Damn. Bad start to this thread. Let me try again another day. Ken ___ macports-dev mailing list

libcxx on older systems (eg 10.6) test and fixes format

Hello, I've been submitting portfile fixes for the above system as I come across them. I've submitted fixes for qt4-mac, aria2, and lilypond so far. But each has a slightly different test format, and there are different opinions about how to do it, so I'd like to standardize that test now. I

Re: libcxx on older systems (eg 10.6) test and fixes format

Hah, hah. Pre-coffee. Great start -- Mountain Lion is 10.8 -- and I think that's the last one we need to test for instead of 10.9, if I recall Jeremy's note correctly. So with 10.8, here: # Snow Leopard with cxx_stdlib=libc++ fix platform darwin { if {{${MINOR} == 6} &&

Re: libcxx on older systems (eg 10.6) test and fixes format

process. Ken On 2016-08-13, at 8:44 AM, Lawrence Velázquez wrote: > On Aug 13, 2016, at 11:11 AM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: > >> I just realized that MINOR is a qt4-mac specific global, not >> a Macports global. And it seeme

portfile test for macosx 10.6.8 + libc++

Hello everyone, I'd like to help with minor porfile adjustments to allow compiling on the above system, within my limited skill set. To allow for an accurate method of specifying a system running 10.6..8 + libc++, can anyone help me with a good test spec to run in a portfile? Do you also

Re: portfile test for macosx 10.6.8 + libc++

:20 AM, Ryan Schmidt wrote: > > On Jul 19, 2016, at 8:25 AM, Ken Cunningham wrote: > >> Perfect. Thanks! >> >> There are a series of EFI32 machines stuck at 10.6.8 or at most 10.7. These >> can be EFI-hacked to run 10.11 but that hasn't worked for me yet. >>

Re: small change in portconfigure.tcl appears to fix missing cxx_stdlib link

with by requiring linking to libc++ in systems that default to libstdc++). This seemed the cleanest way. I'll see if it causes any trouble here, for what that's worth... K On 2016-08-18, at 8:55 AM, Joshua Root wrote: > On 2016-8-19 01:13 , Ken Cunningham wrote: >> For your cons

Re: how about a 'snowleopardfixes' library port?

> > Maybe, if you can make a dylib out of it. > Hmmm. Making the dylib wasn't too hard: clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib and setting it up seems equally straightforward: sudo cp

Re: how about a 'snowleopardfixes' library port?

23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote: >> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 >> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib > > You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here. > >>

port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

Short version: I have a port that builds correctly only with arch=i386. x86_64 builds fail. I can get this to build with "sudo port install basiliskII build_arch=i386" but I can't seem to find the command to specify that the portfile. Is there a way? Long version: I'm working on updating the

Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

> > > This is ludicrous. GCC 4.0 is a decade old. > Oh, way better news. BasiliskII builds and runs, including the JIT, with clang-3.7 at least, when it's held to i386 arch. Apparently nobody has been able to do that before, assuming Dr. Google is correct. Built with arch x86_64 it runs

Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

> Sounds like a jit variant which sets supported_archs may be in order then. > That way users on x86_64 systems can decide whether they want to lose the JIT > or rebuild all the dependencies with +universal. > > - Josh Hey! I feel a little better about my lack of knowledge now -- I think I

Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

I was thinking (and have been) building the emulator with -O3 as I understand from what I can gather from that -O3 prioritizes code speed over code size, and the emulator is both small already and speed-hungry….but I see there is also -Ofast in clang-3.8 (which is what my MacPro is building it

Do I want subports?

Working on the optimal way to do this emulator + GUI program. The emulator itself is best built with i386, for the JIT. This requires libSDL to be available in i386 (so presumably +universal). You can monkey around with a no-JIT version, but you wouldn't want it, ultimately. The rather tiny

newbie python - cmake build problem I can't seem to fix...

Hi all, thanks in advance for the ongoing education, and I apologize for the newbie questions. I'm working on updating a port (hatari) that only builds with python2.7 (or more accurately, doesn't build with python35 selected , but does build with python27 selected). it uses cmake, and

Re: Libpointing

I think the issue in this one is the Makefile, which basically needs to be re-written as far as I can see. I tried to give that a go a few weeks ago for you, but my Makefile-writing skills are still too rudimentary. That is one cryptic language to both read and write. Perhaps one of the

Re: port to install that is a collection of py scripts and a small executable in a folder ...

> > The trac port does something similar in post-destroot (copying some files > into ${destroot}${prefix}/share/trac/contrib and then linking some things > into ${destroot}${prefix}/bin) if you're looking for an example to help. > > -- > Daniel J. Luke I see -- the trac port is very similar

Re: newbie python - cmake build problem I can't seem to fix...

Thanks. Not working so well so far. I might dig into the build script and see what's going on in there, but before I do that is there a way to monkey with the $PATH for the build only, and then set it back to the user's $PATH when we're done? That's cheating, I know.. but I could put

Re: newbie python - cmake build problem I can't seem to fix...

> > You should also file a ticket against hatari. I would -- but I haven't quite finished writing the portfile that would need the ticket filed against it! I'll see if I can fix it without monkeying with the $PATH -- I knew nobody would like that idea... there's something amiss in the python

port to install that is a collection of py scripts and a small executable in a folder ...

Hi all, I thought I'd work on a new requested port, sshuttle. Looks like something I might want to use myself. I have it downloading, building, and running from the build folder, but there is no "make install" component. In the build folder after the build there turns out to be a small mac

Re: newbie python - cmake build problem I can't seem to fix...

> > It's not *bad*, just not ideal. If the build system doesn't respect > PYTHON_EXECUTABLE, then upstream should fix that. True. As it turns out, I learned how to re-write the python to be compatible with 3.x, and fixed the port that way. So that's probably the best outcome, and I'll submit

force a compiler install, or default the port to reduced features?

One of the ports I've been working on (hatari, an Atari ST emulator) was accepted for inclusion. Thank you! Hope everyone enjoys using it. And of course I find out that the preferred variant (a nice MacOSX GUI) doesn't build with the default installation on about the only system I didn't test

Re: buildpath conf variable

On 2016-09-26, at 1:07 AM, René J.V. Bertin wrote: > Hi, > > I know that more and more people (esp developers?) are using SSDs and that > for them fragmentation starts hitting only when it's the free space that's > really severely fragmented. The SSD was the single most impressive speed

Re: I'm a newbie mantainer and I'm confused about the buildbot

On 2016-09-29, at 12:26 PM, Leonardo Brondani Schenkel wrote: > Hi, > > I recently started maintaining some MacPorts packages. For the first time > today I got a message from the buildbot: apparently the neomutt package does > not build on OS X 10.5 PPC due to '_safe_malloc' being undefined

Re: Issues with oudated ports / GitHub

> > The problem is: somebody needs to do the correct work to update each of those > ports to the latest version. In many cases, tickets are already filed, and > you can look them up to see what the current status is; if you don't find a > ticket, please file a new one. Couple of points

llvm / clang and thread_local storage problems

I've run into this again tonight. I'm using, at this moment, clang-3.7 / llvm-3.7 with macports-created libc++ and libc++abi. Every once in a while, a port I'm trying to create or build will error out due to this: error: thread-local storage is not supported for the current target

Re: llvm / clang and thread_local storage problems

On 2016-10-08, at 10:03 PM, Stephen J. Butler wrote: > FYI, it's in the Xcode 8 release notes: > > https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html > > I did a quick test file and it seems to compile with Apple clang. No clue on >

Re: Documentation overhaul

On 2016-10-09, at 6:53 AM, Marcel Bischoff wrote: > there appear to be quite specific views on how everthing here needs to be This is true, and it doesn't take long to notice -- but over 20,000 ports hang tight together and almost all of them work all the way back to Tiger. And that is no

github desktop's request to install command line tools, and macports git command line tools ...

Github desktop seems a useful tool — but it wants to install command line tools (specifically mentioning github utility and git-lfs) into /usr/local/bin. right now, I’m set up with /opt/local/bin/git and I see there already is a port git-lfs versioned 1.4.1 It’s just these kinds of things

review requested - hatari 1.9

Hi, I think this port is ready to launch, and has significant improvements over the existing 1.7 version currently in macports. On updating it, I noticed the port build script uses an undefined python version during compilation, which they should fix someday, but I updated the build script

small change in portconfigure.tcl appears to fix missing cxx_stdlib link

For your consideration this small change in /base/src/port1.0/portconfigure.tcl # Add flags to specify C++ STL implementation if {${configure.cxx_stdlib} ne "" && [string match "*clang*" [option configure.cxx]]} { append_to_environment_value configure CXXFLAGS

"Default" portgroup?

Does there exist a portgroup that might be considered "default", ie port code that would be included on all ports installed on a given machine? If not, it could be useful to have machine or system-specific portfile additions that would apply to all ports on a given machine -- like adding the

Re: how about a 'snowleopardfixes' library port?

That fixed it, indeed. Now works as a dylib as well. Will play with it some more before you/we/I decide what we might to do with it, if anything. Best, Ken On 2016-08-23, at 10:42 AM, Lawrence Velázquez wrote: >> On Aug 23, 2016, at 1:31 PM, Ken Cunningham >> <ken

how about a 'snowleopardfixes' library port?

Snow Leopard has two missing but fairly commonly used functions, getline and strnlen. These two functions are responsible for a number of snow leopard build failures. It seemed that reinventing the wheel over and over for a getline replacement was getting rather tedious, port after port. I

Re: how about a 'snowleopardfixes' library port?

Sorry Clemens, I see now what you mean. During the compile stage, I need to install a name. Thanks for the tip. I missed that first read. Best, Ken >> >> On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote: >>> clang -dynamiclib -std=gnu99 strnlen.c getli

Re: Updating tk +quartz failed on Snow Leopard

On 2016-08-25, at 8:20 PM, Kevin Walzer wrote: > On 8/25/16 10:02 PM, Ryan Schmidt wrote: >> I just haven't researched whether one is supposed to use >> MAC_OS_X_VERSION_MIN_REQUIRED or MAC_OS_X_VERSION_MAX_ALLOWED or >> __MAC_OS_X_VERSION_MAX_ALLOWED or something else. > Can someone try

Re: how about a 'snowleopardfixes' library port?

> > Just another thought, the declaration could be in its own file, > referenced with the compile option -include in CFLAGS/CXXFLAGS, with > conditional #ifdef to add extern "C" for C++. The unused declaration > should not do any harm in other compile units. That way you could even > avoid

Re: how about a 'snowleopardfixes' library port?

>> >> Just another thought, the declaration could be in its own file, >> referenced with the compile option -include in CFLAGS/CXXFLAGS, with >> conditional #ifdef to add extern "C" for C++. The unused declaration >> should not do any harm in other compile units. That way you could even >> avoid

LibCxx on older systems toolchain blew up on 10.6 -- and fixed -- WAS Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

stalls and appears to be a coherent toolchain that works again (with clang-3.8, llvm-3.8). Best, Ken On 2016-08-29, at 1:45 AM, Mojca Miklavec wrote: > On 28 August 2016 at 23:21, Ken Cunningham wrote: >> OK - I see what happened. >> >> All traces of llvm37 have been

Re: I'm a newbie mantainer and I'm confused about the buildbot

> When I updated the install page for Sierra, I left Mavericks on the list, > because that's good cut-off point, with Mavericks being the first OS X > version to use libc++ by default. > > I concur with keeping more Mac operating system releases "supported" by > MacPorts, given Apple's

Re: I'm a newbie mantainer and I'm confused about the buildbot

>> >> I for one am very happy that patches are accepted for older systems, unlike >> homebrew and fink. > > Just curious: where did you get that information? Mojca, you are right, I should read footnotes - I have not personally tried to submit patches to those places, so I can't really say

Re: querying the registry for installed files

Rene, do you mean port provides /path/to/file or something fancier? Ken > On Oct 28, 2016, at 11:41 AM, René J.V. Bertin wrote: > > Hi, > > I think the registry keeps track of all installed files, whether they belong > to active or inactive ports, right? > If so,

Re: [MacPorts] #52663: libcxxabi patch to update to 3.9.0

easy to do -- already have it done, actually, for my own testing. Up to Jeremy, of course. On Wed, Oct 19, 2016 at 7:27 PM, MacPorts wrote: > #52663: libcxxabi patch to update to 3.9.0 > --+ > Reporter:

review request -- sshuttle https://trac.macports.org/ticket/52198

https://trac.macports.org/ticket/52198 I think this port has reached a point where a review would be a reasonable ask. It was a requested port I filled -- a very useful piece of software for me. Helps you access a network behind a router with only ssh access to one machine. Nicely fills a

Re: advanced bash-ing for long compiles

> On Oct 14, 2016, at 7:30 AM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > Some advice appreciated … > Oh, one more similar question while I’m at it. I notice mdworker seems to go nuts during these long builds, often appearing to soak up lots of

Commit request https://trac.macports.org/ticket/52546

For your consideration -- I'd commit this as it stands and fix the port, rather than spend too much more time on it. https://trac.macports.org/ticket/52546 I notice something has changed in the sierra time functions -- a couple of ports seem to have time-related errors. K

Re: Commit request https://trac.macports.org/ticket/52546

That I will leave to upstream. Thanks, K On 2016-10-17, at 6:16 PM, Fred Wright wrote: > > On Mon, 17 Oct 2016, Ken Cunningham wrote: > >> For your consideration -- I'd commit this as it stands and fix the port, >> rather than spend too much more tim

Kudos to Jeremy...

Who has been on a holy terror for 36 hours. Fixing the libunwind bug (on our heads for two years) and updating / advancing all the compiler infrastructure / libcxx / libcxx abi and many other ports Someone gave that man a JOLT cola! Ken ___

Re: Building for 10.5 i386+ppc on 10.6 x86_64

On 2016-10-12, at 2:36 AM, Mojca Miklavec wrote: > Hi, > > A while ago we got a bug report about problems building Perl on 10.6 > x86_64 for 10.5 i386+ppc > >https://trac.macports.org/ticket/52290 > > To what extent is (or should be) this supported? > I would not expect this to be

Re: Closing pull requests

I did close the PR for the ImageMagick openmp submit. I know Ryan hates PRs. I only generated the PR in the first place because I thought it would make life easier for him, which was my only goal. I assumed these were one-click things on your end, as some of my PRs get committed in minutes.

re: [MacPorts] LibcxxOnOlderSystems modified

We should be very careful about modifying Jeremy's LibCxxOnOlderSystems page -- would suggest we just send any suggestions to him, rather than touch that page. Too much detailed info to mess up accidentally. Regarding building and running newer clangs on PPC, there is this report to get you

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

> > The only blocking stone is meeting the agreement about how to > name the new binary archives [and implementing that] :) It would be nice if that discussion was finalized and a plan enacted. Some of the builds on these older machines can take hours and hours... webkit2-gtk is not even to be

review requested - widelands 1.9 update

I think this one looks ready for prime time. https://trac.macports.org/ticket/52188 thanks Ken ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

review request - hatari 1.9 fix for snow leopard without xcode 4.2

I think this does it. https://trac.macports.org/ticket/52537 Thanks! Ken ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: review requested - widelands 1.9 update

Very sorry -- couldn't tell. Thought it fell off the radar! K On 2016-10-07, at 8:10 AM, Ryan Schmidt wrote: > >> On Oct 7, 2016, at 10:08 AM, Ken Cunningham Webuse >> <ken.cunningham.web...@gmail.com> wrote: >> >> I think this one looks re

Re: Issues with oudated ports / GitHub

On 2016-10-07, at 10:05 AM, Rainer Müller wrote: > I am not sure how we could change these to make triaging trickets easier. I can't easily just look at the list and see what are new requests for ports to be included in macports. It all mixed in with other things. Also, the committer time

Re: review requested - widelands 1.8 update

too. Ken On 2016-10-07, at 8:10 AM, Ryan Schmidt wrote: > >> On Oct 7, 2016, at 10:08 AM, Ken Cunningham Webuse >> <ken.cunningham.web...@gmail.com> wrote: >> >> I think this one looks ready for prime time. >> >> https://trac.macp

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

ese ports acceptably quickly. I think the PPC buildbot builds a very good % of the current Macports. <https://github.com/ken-cunningham-webuse/TigerPorts/blob/master/installed_Tiger_Ports_list.txt> K ___ macports-dev mailing list macports-dev@lists

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 2016-10-06, at 7:48 AM, Mojca Miklavec wrote: > On 6 October 2016 at 16:23, René J.V. Bertin wrote: >> >> Ken: apologies for not having thought of this, but myself when I was still >> running 10.6 I've had sufficient success with building C++11 code using a >> (then) recent gcc port. It's