Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

It's been a few months since I went down this rabbit hole, but IIRC, it worked a little better to build clang on ppc directly. 10.5 intel fails to build PPC correctly due to the runtime library issues you stumbled across. The highest i have been able to go is clang-3.6 on ppc so far (building it on

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

On 2017-03-28, at 2:18 AM, Mojca Miklavec wrote: > > It makes absolutely no sense that I try to use a compiler that has > never been designed or tested to produce binaries for PPC. It had always been a design goal for llvm to produce workable PPC code, but although close (lots of things do work

Re: GSoC Proposal

Have you seen how homebrew does this? I imagine he means something like that: Every submission has to be submitted to the 10.10 - 10.12 bots first, to see if it builds. Every submission is suggested / required to have at least a minimal test `myport --version` to make sure something actually wo

Re: [macports-ports] branch master updated: mosh: 1.3.0, switch to CommonCrypto

so this sorta gets back to your question about support for older systems, and is a pretty typical example of same. sounds like you could write up an openssl variant for it, default to that variant on suitable systems, and nobody would likely complain about that. But you might have to do it and

Tiger Virtual Machine on VirtualBox

I know some of you are interested in such things, at times… debugging MacPorts, trying out a port, etc. A Tiger VM more or less works, with a few touchy parts that may or may not improve over time, on the current version of VirtualBox.

Re: Tiger Virtual Machine on VirtualBox

. K > On Apr 22, 2017, at 5:34 PM, Ken Cunningham > wrote: > > I know some of you are interested in such things, at times… debugging > MacPorts, trying out a port, etc. > > A Tiger VM more or less works, with a few touchy parts that may or may not > improve over time

Re: about the libc++ conversion

> simplify the libc++ conversion on older OS X versions I'm working on something related. It turns out that Clang-3.8 / llvm 3.8 builds without too much trouble on 10.5 PPC, using gcc6 to build it (see my trac tickets if you would like to see how to do that). It can then build quite complex

Re: about the libc++ conversion

> However, if I read what's said about this on Linux forums I get the > impression > that the linker should or might raise errors because of the use of different > namespaces. That's right. I've seen errors that look like this, with this std::__1 business: Undefined symbols for architecture x

clang-3.8 on 10.4 and 10.5 PPC - available for testing for the adventuresome

I believe I have clang-3.8 / llvm-3.8 to a state now where people with these machines who are, shall we say, advanced MacPorters might want to waste a few minutes (and four hours building) to try it. If setting up a repo and figuring out your own dependencies is not peanuts for you, I wouldn't s

how to install a subport rather than the main port from a local Portfile not in a repository

Long title … If you download a Portile into a folder, you can quickly install or work with it with “sudo port -v install”, You don’t specify the name, and the primary port in the local Portfile is used. Is there a way to work with a subport contained in that Portfile in a similar fashion? Spe

Re: how to install a subport rather than the main port from a local Portfile not in a repository

Thanks! Sorry to ask a previously-answered question… Ken > On Jun 11, 2017, at 7:36 AM, Daniel J. Luke wrote: > > On Jun 11, 2017, at 10:27 AM, Ken Cunningham > wrote: >> Is there a way to work with a subport contained in that Portfile in a >> similar fashion? Sp

Re: Installing WINE

Did this Very Big Problem with Wine64 on MacOS actually get fixed? K https://www.winehq.org/pipermail/wine-devel/2014-February/103074.html > I don’t know the exact details myself (Ken is the expert), but the answer is > that it does not work, and probably never will. OSX has a ABI incompatibil

Re: application scope of configure.optflags, configure.compiler

> Is there any existing way I can get the configure.optflags or > configure.compiler command line argument to apply to multiple ports? for configure.compiler, setting default_compilers macports-clang-3.9 or whatever one you want seems to do the equivalent of setting configure.compiler fo

looking for a little help and feedback for irrlicht port (to enable minetest)

In my ongoing quest to bring every major open-source game to MacPorts, I've been working on minetest. Minetest is reported to be the #1 most popular open-source game on the internet. It's been in homebrew for a long time, but was broken there. I fixed it about six months back for homebrew, but

Re: c++ library usage

>> >> - it was slightly easier to switch the system compiler/stdlib (in >> particur switching to the latest gcc on 10.5 for example) That particular piece is fairly easy. Just put this in macports.conf: default_compilers macports-gcc-6 and you're done. Every port will compile with gcc6, over

Re: looking for a little help and feedback for irrlicht port (to enable minetest)

Thanks for looking, Craig. I think you may have stumbled across this error. Ken >> My build file and patches are here: >> >> >> The minetest portfile and associate

some PRs for new and updated games ready to commit when you have a moment

Hello, all -- I believe the following additions and upgrades to macports games collection are in supportable condition, and IMHO are all ready to join the main Macports repository when/if you have a moment. -- Thanks, Ken scummvm: update 1.90, add devel version all Travis test build pas

Re: Tiger Virtual Machine on VirtualBox

10.4 has borne fruit. See this thread for more if interested: <https://lists.cairographics.org/archives/cairo/2017-January/027836.html> Ken On 2017-05-02, at 12:28 PM, Joshua Root wrote: > On 2017-4-23 10:34 , Ken Cunningham wrote: >> I know some of you are interested in such t

Re: Buildbot now fails to build wine dependencies

On 2017-06-27, at 2:31 AM, Ryan Schmidt wrote: > We used to be able to build wine on the buildbot, but we aren't anymore: > > https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791 > > The error occurs when installing dependencies, specifically cairo: This would also be w

running clang compiler test suite from within macports infrastructure?

I suspect only Jeremy or LarryV could answer this, but is it possible to run the llvm / clang compiler test suite from within the macports infrastructure? The clang build on macports is very heavily modified with patches and configuration settings - it seems overwhelming to try to duplicate that

Re: gcc & libgcc 6/7/8

I think that's it. libgcc @6.x can service all the gccs from about 4.7 to 6.x, so there is only one. Too bad we need a new version for gcc7. More complexity, more complications. But that's progress. Hopefully the broken gcc7 build on older systems can be remedied. Ken On 2017-06-30, at 7:33

Re: running clang compiler test suite from within macports infrastructure?

Thanks, Jack. There appear to be different ways to test clang. I thought the testing would all happen in during or related to the build, but this does not appear to be exactly so. At any rate, there is a "test-suite" of 400+ tests for each version of clang, which is one way to test it. It is u

Re: running clang compiler test suite from within macports infrastructure?

I thought we had fixed). Gives me encouragement to continue on with clang-3.8 on PPC. Ken On 2017-06-29, at 5:33 PM, Ken Cunningham wrote: > I suspect only Jeremy or LarryV could answer this, but is it possible to run > the llvm / clang compiler test suite from within the ma

Is it time for a libc_fixes library yet?

So the last 10 or so tickets in trac seem like they are all for basically the same issue - a few missing symbols from libc prior to 10.7. It is easy enough, but time consuming, to patch each individual source file that is missing the definition (there might be several, also, so you might have t

Re: Is it time for a libc_fixes library yet?

09 PM, Rainer Müller wrote: > On 2017-07-03 19:07, Ken Cunningham wrote: >> So the last 10 or so tickets in trac seem like they are all for >> basically the same issue - a few missing symbols from libc prior to 10.7. > > Well, I would take this as a reason to just drop support fo

Re: Is it time for a libc_fixes library yet?

p.c.auto.html > > https://opensource.apple.com/source/Libc/Libc-1158.50.2/string/FreeBSD/strnlen.c.auto.html > > > > > On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham > wrote: > I see a general frustration with the current situation has led things to move > along r

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Thanks -- these kinds of nuances are tricky. Will alter that and update. Ken On 2017-07-04, at 1:29 AM, Ryan Schmidt wrote: > >> On Jul 3, 2017, at 14:46, Marius Schamschula wrote: >> >> Marius Schamschula (Schamschula) pushed a commit to branch master >> in repository macports-ports. >>

Re: Is it time for a libc_fixes library yet?

> > Your library offers multiple functions... getline, strndup, etc. > > What happens if a software package provides, for example, a compatibility > implementation of getline but not strndup? Can your library be used in this > case or will that also "cause trouble", as you put it above? Very

Re: Is it time for a libc_fixes library yet?

> > > Perfect would be if I just wrote it into the clang code directly. I am almost > to the point where I could do that, actually. I know where it would go, I > think. > Well, another fairly easy option would be to bring down the newer libc from 10.7 and port it back into 10.4 to 10.6, with

should depends_lib really mean depends_lib-append ??

This feels like something that has likely been discussed before Now that PortGroups have important depend_lib-append, etc, in them, we don't want Portfiles to reset these by accidentally using depends_lib and trashing them, and yet this is easily done: See

Re: Dropping recommendation to install system headers / command line tools

> > Yea, compilers that assume /usr/local must be searched for include files are > broken. Other than that, what else is the issue? > > — I wasn’t around for it, but I think in the beginning /opt/local was chosen for macports in part because /usr/local was being heavily used by darwinbuild an

Re: [macports-ports] branch master updated: cxx11 1.1 PortGroup: add support for PowerPC

Sorry 'bout that. https://github.com/macports/macports-ports/pull/563 On 2017-07-05, at 1:06 PM, Rainer Müller wrote: >> _resources/port1.0/group/cxx11-1.1.tcl

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

> > Why muniversal? > The fact that the universal build succeeds and actually produces universal > binaries suggests the muniversal portgroup isn't needed. All you need is > "variant universal {}" after "use_configure no". > thanks for fixing that. I just used muniversal because I saw the por

hedgewars PR request to commit

Hello, all - request to commit https://github.com/macports/macports-ports/pull/522 This one I believe needs no more attention - it's been looked over well enough I think to go ahead and commit. It's getting close to scrolling off page 1 of the PR list, and page 2 is never never land :> Best,

Re: Possible patch for sox build failure on 10.7

I'm travelling with a 10.7 laptop this summer (hence the rash of 10.7 fixes I've sent up over the past month). Can give it a try. --K > On Aug 9, 2017, at 1:05 AM, Joshua Root wrote: > > Perhaps someone with access to a 10.7 machine could try this. > > - Josh >

Re: Possible patch for sox build failure on 10.7

> Thank you Josh. I missed ./configure --disable-silent-libtool. I am a bit confused about this. According to >, disable-silent-

configure.compiler=macports-clang-devel doesn't work. Is there a proper value?

Doesn’t seem to be an entry for clang-devel in > and some trial and error didn’t find it easily… Also, can’t spot an entry in

should cxx11 1.1 PortGroup also blacklist older clangs (< 600, say) during libc++ builds?

The libstdc++ section of this portgroup forces clang 4.0, and the PPC section forces gcc6. Those cover almost all current port compiler requirements. But there is still a hole in the libc++ section, and it happens often enough that older clangs (< 600 or so) have to be blacklisted on older syste

Re: should cxx11 1.1 PortGroup also blacklist older clangs (< 600, say) during libc++ builds?

I’m sorry - retract this. I see there is already a section where this is done that I had glossed past before. I’ll have to look into why I still need to fiddle with this sometimes. Sorry for noise. Ken > On Aug 12, 2017, at 3:02 PM, Ken Cunningham > wrote: > > The libstdc+

how to efficiently work through generating patches using git and macports build process?

I'm looking to improve my efficiency. When trying to fix broken ports, I have so far been using the method of copying the source file to source.orig, editing the source files in place, and then noting the files I worked on, to individually diff them at the end to individual patch files. It's e

Re: how to efficiently work through generating patches using git and macports build process?

> > Didn't we have a set of "shortcuts" that included the commands for > setting up the local GIT repo? Might be worthwhile for folks with such > shortcuts to push a link to this list (again). - MLD I do use a git repo to branch the macports port tree, to record portfile changes and patches that

Re: how to efficiently work through generating patches using git and macports build process?

> >cd $(port work foo) >cd foo-version >sudo git init . >sudo git add -A > >git diff > /tmp/my-patches.diff > > And more or less make sure that you don't do "sudo port -v install" > without, say the "-k" flag to keep the files before your run "git > diff". > This is what

Re: how to efficiently work through generating patches using git and macports build process?

On 2017-08-30, at 9:41 AM, Michael Dickens wrote: > What Mojca wrote is what I do too. Simple but very effective! - MLD > Is there a way to make git ignore the *.o and *.a and other generated files that might be in the source tree that we're not interested in tracking -- or does the -A do tha

Re: how to efficiently work through generating patches using git and macports build process?

All this is very helpful. Thanks! Ken > Hope this helps! - MLD > > On Wed, Aug 30, 2017, at 12:50 PM, Ken Cunningham wrote: >> >> On 2017-08-30, at 9:41 AM, Michael Dickens wrote: >> >>> What Mojca wrote is what I do too. Simple but very effective! - ML

review requests

Hello, fellow MacPorts developers. While I am waiting for my commit permissions to be considered, I would appreciate anyone with some spare time and enthusiasm to consider a few PRs for committal/commission: Lout: a port update requested by a devoted MacPorts user on Sierra that needed to be

Re: Switching cxx_stdlib for C++11 on legacy macOS (was: Re: [GSoC] migration)

> > As stupid as it seems but I don't see any cxx_stdlib option in my > macports.conf (see attached). base defaults it to stdlibc++ on <10.9, and libc++ on 10.9+ behind the scenes. > > Sure, this is a helpful point to keep in mind. Though, any reasons to not > switch to libc++? Although I p

Re: Switching cxx_stdlib for C++11 on legacy macOS (was: Re: [GSoC] migration)

On 2017-09-02, at 11:04 AM, Ken Cunningham wrote: >> >> As stupid as it seems but I don't see any cxx_stdlib option in my >> macports.conf (see attached). > > base defaults it to stdlibc++ on <10.9, and libc++ on 10.9+ behind the > scenes. libstdc++ , not stdlibc++ haven't had coffee yet.

Re: Switching cxx_stdlib for C++11 on legacy macOS

> As I understand it, to support C++11 the only way is to switch to > libc++. That was true a year ago, but is no longer true. The cxx11 1.1 PortGroup offers c++11 support for all systems back to Tiger with no change in the standard library. There is no good reason to change to libc++ on those

Re: Switching cxx_stdlib for C++11 on legacy macOS

On 2017-09-03, at 2:16 PM, db wrote: > > Wouldn't switching cxx_stdlib to and having the bots build binaries with > libc++ actually benefit both developers and users? > DIscussed absolutely to death. I use libc++ and would prefer we change to that. Everyone else is afraid of the pandemonium

Re: Switching cxx_stdlib for C++11 on legacy macOS

On 2017-09-04, at 1:43 AM, Ryan Schmidt wrote: > > I have not followed the development of the cxx11 1.1 portgroup so I don't > know the benefits and drawbacks of using it compared to using libc++. After digging into this for a year and debugging and fixing a _great many_ ports, here are my t

specifying needs for qt ports

Hmm. Bit confusing, and these qt PortGroups are a little thin on documentation. I am working on a port that can build with qt4 or qt5 (any version). Looking through the PortGroups: the qmake 1.0 PortGroup sets up the build and calls the qt4 PortGroup the qt4 PortGroup sets up the proper depende

Re: New project member: kencu

Thanks very much, everyone of you, for the education over the past while. I appreciate your patience and wisdom. Glad to be part of the group! Best, Ken On 2017-09-11, at 6:26 AM, Rainer Müller wrote: > Please join us in welcoming the following new MacPorts project member: > &

"include" files in Portfiles - not PortGroups

Not meaning to engender too big of a discussion about how good an idea it might or might not be, but Is there a method for having a Portfile that does something like the following? -- # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-

Some opinions on whether there be a guile20 port?

guile moved to 2.2.2 a few months ago, and at least two ports that link against guile 2.0.18 broke when 2.2 rolled out: geda-gaf and autogen . An outside patch will let

Re: Some opinions on whether there be a guile20 port?

Ah, the old version is 2.0.14, not 2.0.18, apologies for the typo. K On 2017-09-13, at 10:22 PM, Ken Cunningham wrote: > guile moved to 2.2.2 a few months ago, and at least two ports that link > against guile 2.0.18 broke when 2.2 rolled out: > > geda-gaf <https://trac.macp

Re: Some opinions on whether there be a guile20 port?

> > geda-gaf > The other broken port(s) can no doubt be patched too. > > Actually, it looks like upgrading geda-gaf to use guile 2.2.2 may not be so easy after all. It may be stuck using guile 2.0.14 for some while. K

travis builds time out -- then keep restarting ???

Something funny is going on with travis today. The builds keep restarting after timing out at 48 mins, I think

Re: how to efficiently work through generating patches using git and macports build process?

Just like to say that this method works extremely well. Thanks! Ken On 2017-08-30, at 11:19 AM, Michael Dickens wrote: > You can always create or add them to a .gitignore file. If at the top-level > GIT repo, this file impacts the whole repo. You would literally add "*.o" > (but without the

Re: travis builds time out -- then keep restarting ???

this is still going on. some travis builds have been running almost 6 hours, which would be great if they finally built something, but looks like it just keeps resetting and starting over... > On Sep 15, 2017, at 3:37 PM, Ken Cunningham > wrote: > > Something funny is going on

ignore "portfile changed" ?

when working on the destrooting of complex ports it is tedious to have the ports rebuild with each portfile edit, esp the big ports that need the complex destrooting It must be possible to override this -- I feel I'm missing something simple somewhere. I hope this detail is not just buried

Re: ignore "portfile changed" ?

thank you I don't think to check the man pages enough for macports issues. I will go look there more often. -- Ken > On Sep 17, 2017, at 7:41 AM, Rainer Müller wrote: > >> On 2017-09-17 16:35, Ken Cunningham wrote: >> when working on the destrooting of complex port

buildbot fetch of ghc fails on 10.8 or less due to SSL error

I have not seen this one here at home when installing ghc-bootstrap or ghc, but I presume it's due to the older SSL in MacPorts causing trouble: Error: Failed to fetch ghc-bootstrap:

Re: [macports-ports] branch master updated: ghc and ghc-bootstrap: specify compiler to clang-4.0

On 2017-09-27, at 6:20 AM, Ryan Schmidt wrote: > > MacPorts automatically adds a build dependency on the compiler it uses, if > that compiler comes from MacPorts and if that dependency has not already been > added, so having already specified the compiler whitelist you don't then also > need t

Re: [macports-ports] branch master updated: mosh: allow build with systems < 10.7

> > This doesn't build on Lion: > > https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/43805 > Noted. I was "sure" 10.7 had that capability, but it clearly doesn't at least on this build. I'll move the system test up to 10.8, once I verify that 10.8 built it. Thanks,

build errors on 10.13 due previously default macro now undefined

Previously AssertMacros.h defined this by default. #define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 1 Now it does not. There have been a number of build failures due to this, and we're sure to see more. The immediate fix is to redefine the Macro. Longer term is to move the new na

Re: Macports Clang 3.9 compilation failures due to missing include

Hi Chris, Looking over the xrootd commit, and to hopefully make your life much easier when using the PortGroup cxx11 1.1, you generally don't need to do much of anything beyond adding the PortGroup. You can pretty much expect to delete all the other compiler selection components in your Portfil

Re: [macports-ports] branch master updated: gnutls 3.5.15: add doc variant

> But similar to cxx11 1.0, it doesn't do much on systems using libc++, i.e. > 10.9 or later. > The only thing it does if libc++ is selected is blacklist { clang > 500 } and *gcc* Ken

Re: [macports-ports] branch master updated: gnutls 3.5.15: add doc variant

argh blacklist { clang < 500 }, I meant On 2017-09-29, at 11:47 AM, Ken Cunningham wrote: >> But similar to cxx11 1.0, it doesn't do much on systems using libc++, i.e. >> 10.9 or later. >> > > The only thing it does if libc++ is selected is blacklist { clang > 500 } > and *gcc* > > Ken

buildbot force build a variant?

I'd like to force a build of webkit2-gtk +quartz on 15 & 16 to make sure my recent fixes play out as I think they will. After trying a few things, I can't seem to find the trick for that (if there is one). Is it possible to force a non-default build on the buildbot? Thanks, Ken

Re: buildbot force build a variant?

Ah, thanks very much for pointing out the ticket. I see now. I will stop trying things :> Ken On 2017-09-30, at 10:17 PM, Mojca Miklavec wrote: > > 30. sep. 2017 9:20 PM "Ken Cunningham" wrote: > I'd like to force a build of webkit2-gtk +quartz on 15 & 16

virtual machine for 10.5 intel ?

if anyone would care to enlighten me on the best approach to making a VM for 10.5 intel, I would appreciate it. This is the only system I have that I can’t presently see a way to virtualize. Thanks, Ken

Re: virtual machine for 10.5 intel ?

Thanks for the ideas, Ken On 2017-10-03, at 12:49 AM, Mojca Miklavec wrote: > On 3 October 2017 at 05:01, Ken Cunningham wrote: >> if anyone would care to enlighten me on the best approach to making a VM for >> 10.5 intel, I would appreciate it. This is the only system I have t

Re: [macports-ports] branch master updated: fish: fix build on Tiger

Thanks, will do. I was originally going to range it — then realized I was already at the bottom of the OS pile, and darwin 8 was as low as we can go :> It gives me such odd satisfaction to keep these old machines in current software … reduce, reuse, recycle, all that. Ken > On Oct 7, 2017, a

license question

I'm fixing up a submission for a piece of software called `profanity`. I think the license should be {GPL-3+ OpenSSLException} but I don't exactly know what OpenSSLException means. Do I have it right? Thanks. Ken Here is the blurb. = Profanity Copyright (C) 2012 - 2017 James Booth P

perl module expert needed...

There is a rather fancy genome sequencing port submitted that is hung up on a few missing perl modules, if anyone can help Checking Required Perl Modules: XML::Compile::SOAP11 missing. Used for downloading sequence databases from RSAT XML::Compile::WSDL11

Re: perl module expert needed...

> On Oct 13, 2017, at 10:46 PM, Joshua Root wrote: > > > They're on CPAN: > > > > > What help do you need? > > - Josh I got bogged down in cpan2port and thought someone might have done lots of

Re: [macports-ports] branch master updated: macports-notifier: update to more recent version

On 2017-10-16, at 12:41 PM, Ryan Schmidt wrote: > However you have an Xcode-based build system, and I'm not certain how best to > supply variables to it at build time. I added this port recently, with exactly that potential use in mind: $ port search mulle mulle-xcode-settings @1.2.5 (devel)

Re: https fetch error on older (<10.9) OSX releases due to rejected protocol

Please see I Ken On 2017-10-18, at 12:39 PM, Christopher Jones wrote: > Hi, > > I just just been looking into a build failure on older OS in one set of > python ports, pyXY-bleach, that is a dependency of a port I maintain. > > It looks lik

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

; >> https://github.com/macports/macports-ports/commit/e1f1b6b20678fed08e81f8a65ea0062f59a1f64c >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new e1f1b6b ffmpeg: force gcc6 on PPC >> >> e1f1b6b is described belo

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

> On Oct 20, 2017, at 7:39 PM, Ryan Schmidt wrote: > > I guess my question was: is there something unique about ffmpeg that makes it > require gcc6 on PowerPC, as opposed to one of the alternatives MacPorts would > choose, or is MacPorts choosing inappropriate alternatives for all ports on >

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

> > > The issue in doing that is that C++ ports will possibly be build > inconsistently because macports-gcc6 will use the MacPorts-provided runtimes > from libgcc which are not compatible with the host's libstdc++ (used by > gcc42). > > If you want to use gcc6 for a full build of MacPorts on

Re: Request for Feedback

I'm interested, and greatly appreciate your effort in taking this issue on! I hope we can reach a consensus on this. K > On Oct 21, 2017, at 10:11 PM, Marcus Calhoun-Lopez > wrote: > > I have created a new PortGroup to test possible changes to the base > code concerning compiler selection. >

Re: [macports-ports] branch master updated (27855f9 -> 8d04fcb)

I suggested that to the OP, but no response... It is admittedly a bit tedious to clone his entire repo to fix it for him, and the lure to do it right in the browser is strong when it takes but 5 seconds to fix on the web interface -- Are we sure we don't want to enable the 'squash and merge' op

Re: Question about compiler blacklisting (llvm-gcc for wxWidgets)

I know it's not the party line, but IMHO to minimize hassles supporting these older systems we might well just flush them all to build everything with clang-4.0 or 5.0, to match the newer systems. Then most all systems would see similar or identical errors. I'm not too clear on why it's worth

Re: Question about compiler blacklisting (llvm-gcc for wxWidgets)

> On Nov 2, 2017, at 12:20 PM, Ryan Schmidt wrote: > The part where it allows a port to be compiled with MacPorts libstdc++. Why > is this ok? Didn't we used to have the problem that C++ software compiled > with gcc would crash because it used new gcc libstdc++ but a library it used > was us

interesting tool - deploymate - scans software for MacOS SDK needs

I thought I would mention a tool I came across recently that might be of some use to people on this list who are sometimes tasked with making software runnable on older systems. Deploymate scans source code for SDK dependencies, and will list certain MacOS SDK cal

Re: [macports-ports] branch master updated: cmake: require C++11 for both release and devel.

On 2017-11-06, at 7:13 PM, Ryan Schmidt wrote: > Wow, this really sucks. It means that on Mountain Lion and earlier, cmake now > depends on clang-5.0, clang-4.0, clang-3.9, clang-3.8, and clang-3.7, and on > Lion and earlier, also clang-3.4. It also says all compilers are blacklisted > so I'm

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-06, at 11:35 PM, Leonardo Brondani Schenkel wrote: > Hello all, > > I recently introduced a new port, xdxf_makedict, which built successfully on > my box (macOS 10.13) on first try. However, after it got merged I started > getting notifications from the buildbots about build failure

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:03 AM, Ken Cunningham wrote: > > On 2017-11-06, at 11:35 PM, Leonardo Brondani Schenkel wrote: > >> Hello all, >> >> I recently introduced a new port, xdxf_makedict, which built successfully on >> my box (macOS 10.13) on first try. Howev

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:27 AM, Ken Cunningham wrote: > > -- Found libintl: /opt/local/lib/libintl.dylib > > so perhaps there is a missing dep for port:libiconv > > Ken > > No, seems you have that dep there. Maybe it's the newer compiler... I'll include

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:30 AM, Ken Cunningham wrote: > > >> >> -- Found libintl: /opt/local/lib/libintl.dylib my error - blurry eyes. like josh said, this is provided by gettext. perhaps gettext is the real missing dep.

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 2:13 AM, Joshua Root wrote: > > > There is an indirect dependency via glib2. The issue really is the macro > in the gettext header causing unintended changes to the C++ headers. > > - Josh totally get it now. It builds easily with libc++, but fails with libstdc++ or macport

Re: Help needed: fix build issue with xdxf_makedict in older platforms

> > Unfortunately that did not work for me, the port fails at the configure phase: > > -- The C compiler identification is Clang 5.0.0 > -- The CXX compiler identification is Clang 5.0.0 > -- Check for working C compiler: /opt/local/bin/clang-mp-5.0 > -- Check for working C compiler: /opt/local/b

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 2:20 PM, Joshua Root wrote: > > > Looks more like it was made to support programs using gnulib, which > apparently provides its own setlocale implementation. I would probably > have tried including the gettext header last before undefining the macro. > > The intent of having t

Re: [macports-ports] branch master updated: util-linux: add snowleopardfixes

This ticket this fix came from predated the snowleopard_fixes portgroup. You're quite correct - since the portgroup was committed, that would be the proper fix now. -- K On Fri, Nov 10, 2017 at 5:59 PM, Ryan Schmidt wrote: > > On Oct 19, 2017, at 08:57, Kurt Hindenburg wrote: > > > Kurt Hindenb

Re: gimp on HS

On 2017-11-13, at 9:16 AM, Rainer Müller wrote: > > regenerated with our patched version. The bug report [1] against > intltool never received any attention from upstream. > [1] https://bugs.launchpad.net/intltool/+bug/1197875 It's always amazing to me how anything less than an obsequious note

how to build against an older SDK - library not found for -lcrt1.10.6.o

Hi, smart people. I'm trying to write up a Portfile (for TenFourFox) that requires building against an older SDK (10.4u) and I'm on 10.6 Intel. It's easy enough to pass in the sysroot configure.cxxflags-append -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk configure.cflags-app

Re: how to build against an older SDK - library not found for -lcrt1.10.6.o

> > > Are you also using a 10.4 deployment target? > > - Josh I think that might be it. If you don't pass -macosx-version-min to the linker, it assumes 10.6. I'll work on that. Thanks, Ken

Re: how to build against an older SDK - library not found for -lcrt1.10.6.o

On 2017-11-15, at 8:49 AM, Ryan Schmidt wrote: > > > You don't need to do that manually. Just set "configure.sdk_version 10.4"; > MacPorts then adds the right -isysroot flags for you. > thanks. I will look into doing just that. And by the way, I'd like to have a chat one day with the fellow

haskell base library >= 4.8 ?

Hi all, I'm updating hedgewars, and there is a build error (see below). The hedgewars devs say this means the base library is too old, and needs to be >= 4.8. I don't actually know what version of the haskell base library we have at present, or how to update it (if we can). Any ideas how that

<    2   3   4   5   6   7   8   >