Re: Closing pull requests

[Ken Cunningham]

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. When I saw the PR was 
not helping, I left it here as a patch in the  original ticket, as he seems to 
prefer that, and all the info might as well be in one place for a searcher.



Similar with the fix for upc. I don't know where tenomoto is, but this one sat 
for about a month, and also has a ticket, so I left the fix there and closed 
off the PR as redundant. People will search trac when upc fails to build, and 
find the fix there.

darwinbuild-legacy:

Well, that one is a bit petty, I'll admit, and I closed that in the string of 
them. It's an ancient, rather messed up port that doesn't use the right 
compiler and would never in a million years pass a thorough inspection for a 
new submission today, but it works perfectly fine on the machines that it's 
targeted towards.. Jeremy asked me to see if it could be made available for 
another project I'm working on. I am curious why that "commit" button didn't 
get hit there..I demonstrated it built and worked fine on 10.4PPC and 10.5PPC 
-- .but from your note, I now realize committing a PR is quite a bit more 
involved than just popping a button, which is a pity. Now that I know that, I 
won't have expectations of anything.

One comment, though. I know about the manpower, and the volume. I get it. And I 
recognize all the work everyone does to keep things rolling (including what I 
do).

But if MacPorts is really trying to increase usage and get more participants, 
it might be difficult to sell that if submissions and fixes take months or even 
years to get in.

Just food for thought.

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

re: [MacPorts] LibcxxOnOlderSystems modified

[Ken Cunningham]

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 started playing if you like, and shows how to solve the supported_archs 
issue you had.

https://trac.macports.org/ticket/53184


It is quite complicated to move newer clangs to PPC, and in the end likely to 
be pointless, because PPC code coming out of clang / llvm is unreliable and 
there is no current plan to fix it. Some things might work on a spotty basis, 
for whatever good that is.


I would like to find some way of handing newer ObjC files on PPC, but don't 
really see that every coming. 

For now, if  your source doesn't build with gcc42, and if gcc5 or gcc6 doesn't 
handle the ObjC in the source, you're out of luck.


Ken

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Kudos to Jeremy...

[Ken Cunningham]

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


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: querying the registry for installed files

[Ken Cunningham]

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, is there a way to query the registry with a filename pattern, to 
> obtain the full paths of known matching filesand the port(s) which provide 
> them?
> 
> Thanks,
> René
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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:  ken.cunningham.webuse@…  |  Owner:  jeremyhu@…
>   Type:  submission   | Status:  new
>   Priority:  Normal   |  Milestone:
>  Component:  ports|Version:  2.3.4
> Resolution:   |   Keywords:  haspatch
>   Port:  libcxxabi|
> --+
>
> Comment (by larryv@…):
>
>  I think the LLVM project clearly has a preference for CMake at this point.
>  We should probably switch to it for this port as we already have for the
>  LLVM ports.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for the Mac operating system
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 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.
> 
> Presumably this is because Apple has finally gotten around to implementing
> clock_gettime() in Sierra, and that's colliding with some
> locally-provided replacements.  Typically a configure script would
> determine whether clock_gettime() is available, or whether to provide a
> replacement.  Making that work properly is better than just commenting out
> the colliding typedef.
> 
> Fred Wright
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

[Ken Cunningham]

> 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 cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 need I had to access a hylafax server behind a firewall that has 
been an issue for me for years.

It is close to prime-time ready, but there is one hiccup.

There is something weird about the install process - it pauses for up to two 
minutes at a certain point, looks like it's hung, but then proceeds on. I 
assume something times out, but I can't figure out what it is.

Look forward to any comments.

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Building for 10.5 i386+ppc on 10.6 x86_64

[Ken Cunningham]

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 supported at all. It never has been, to my 
knowledge.

However, it's not necessary anyway. Perl builds fine on all systems back to 
Tiger (I added some evidence to the ticket report).

Best,

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Documentation overhaul

[Ken Cunningham]

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

So there are big payoffs to a guiding hand. And there are ready teachers around 
here who know an awful lot.

Maybe that is part of what the new kids will need to see and absorb as well...

K___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Ken Cunningham]

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 
> compatibility issues though.
> 

Thanks!


> Thanks for finding and sharing that information. It sounds like you could get 
> TLS by using MacPorts clang instead of Xcode clang, but that it will be 
> incompatible with whatever TLS implementation Apple eventually creates.


I had hoped it would be in the macports-clang-3.7 build I'm using, but it seems 
to error out.

However, I noticed this bit in the the libcxxabi port 

libcxxabi-3.7.0.src/include/cxxabi.h


#ifdef __linux__
// Linux TLS support. Not yet an official part of the Itanium ABI.
// 
https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
extern int __cxa_thread_atexit(void (*)(void *), void *, void *) throw();
#endif

and - if I open up that guard, it actually builds cleanly on MacOSX.

I wonder if TLS support was just disabled on all but Linux...perhaps I'll try 
installing this new version I just built and see what happens. --- after I back 
everything up :>

Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

llvm / clang and thread_local storage problems

[Ken Cunningham]

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

/opt/local/var/macports/build/_opt_myports_devel_glbinding/glbinding/work/build/source/glbinding/include/glbinding/glbinding_features.h:240:36:
 note: expanded from macro 'GLBINDING_THREAD_LOCAL'
#define GLBINDING_THREAD_LOCAL __thread
   ^

In this case, I'm trying to create this port 
 which is a dev library for openGL.


As I understand it, thread_local storage is a feature of cxx11 that should be - 
but apparently isn't - supported by clang / llvm.

This page  says it is enabled in 
clang-3.3, if your c++ runtime provides __cxa_thread_atexit, like libc++abi 3.6 
or later.
I have   libcxxabi @3.7.0_1+universal (active) platform='darwin 10' archs='i386 
x86_64'

there's a thread on stackoverflow about it:



which has this quote:

For Xcode 7.x and earlier, here is an answer from 2014 from an Apple engineer 
on the Apple Developer Forum:

We don't support the thread_local implementation from the open-source Clang 
because we believe we can provide a higher-performance implementation for our 
platforms using various features in the dynamic linker. Such an implementation 
would be ABI-incompatible with the implementation in the open-source Clang, so 
we won't support thread_local until we get an implementation we can live with 
for the foreseeable future.

There are many smart people on this list who know a lot more about this kind of 
thing than I ever will.

Anyone offer any insight into this issue?

best,

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: review requested - widelands 1.8 update

[Ken Cunningham Webuse]

Oh - I should say -- if there is anything about that last widelands portfile 
you'd like me to work on, just mention it. (I guess my email said 1.9, but the 
portfile is for 1.8)

The next version of widelands (1.9) is up for fairly imminent release now as 
well, and so I'm working on that one now 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.macports.org/ticket/52188
> 
> I had been working on that, and have further changes locally not mentioned in 
> the ticket.
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ken Cunningham Webuse]

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 needs to be more protected to keep things moving more 
quickly. The fairly small group of committers with the deep MacPorts knowledge 
and experience frankly doesn't have time to do the mass of grunt work. They 
should be mostly reviewing and commenting on other's work, sending things back 
for needed fixes, rather than writing much themselves. And there might need to 
be a distinction between style critique and actual function failures, as things 
do have to move along.

Like Ryan said, I'd have separate queues for each major category..let's see -- 

new incoming port requests that anyone could claim - port that don't 
exist in macports at present

new portfiles that have been finished and are awaiting committer review

requests for updates to existing ports by people who have noticed 
something out on the web of significance. 

port updates with patches (approved by maintainer if there is one) 
waiting for committer review


> Requests for new ports could still be valid after years. This list could
> be helpful for newcomers that want to create new ports. 

Totally agree - but I'd close everything over six months old or something like 
that for optics. People can still search to "closed" tickets if they want.

I'm still thinking of resurrecting the hylafax portfile from 8 or so years ago. 
And I did just use the webmin portfile from about the same vintage two weeks 
ago :>


Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ken Cunningham]

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

The current "port update" ticket queue I find to be a rather unpredictable 
mixture of requests of port updates, requests for new ports, announcements that 
somebody has noticed a version update has come available, and finished port 
updates awaiting approval by committers. I don’t mind picking off a few of 
these and updating them, or building some new ones, but it’s a bit of a tangle 
sometimes.

Like this ticket:
https://trac.macports.org/ticket/52538

I think this ticket represents someone noticing there’s a new version 
available, and requesting the existing port be updated. But that should be in a 
different lineup, IMHO.

And there are "requests for ports" ( I think this means new requests for ports 
that don’t presently exist, mostly) that go back 11 years. Port submissions 
that go back the same length of time. Possibly some kind of massive clean-out 
of the old, dead, never-will-be-touched stuff might need to happen.

Might be more streamlined and efficient if that all could be aligned better.

$0.02.

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

[Ken Cunningham Webuse]

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

[Ken Cunningham Webuse]

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 ready for prime time. 
>> 
>> https://trac.macports.org/ticket/52188
> 
> I had been working on that, and have further changes locally not mentioned in 
> the ticket.
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

review requested - widelands 1.9 update

[Ken Cunningham Webuse]

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

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

[Ken Cunningham Webuse]

On 2016-10-06, at 9:40 AM, René J.V. Bertin wrote:
> 
> Wow ... have you also thought about my mom's old blue baby iMac G3 which 
> still runs AFAIK? :D And maybe providing a newer Mach kernel for them, too?

Indeed, it's surprising to me as well sometimes just how useful these machines 
still are. MacPorts has proven to be very resilient over time, thanks to the 
efforts of many.

Just FYI, here's a list of the current ports one of my PPC tiger machines runs 
just at the moment... 700 installed ports, although some are duplicates / 
updates. And the DualG5s and DualG4s run these 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.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham Webuse]

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 possible that things have evolved so much 
>> nowadays that even that may not cut it anymore.
> 
> This would probably mostly work fine if *all* ports were built with
> g++ (= against the same version of mp-provided stdlibc++). I can
> easily imagine problems when gcc is switched from, say, version 5 to


10.6+ work great with libc++. I wouldn't feel a need to explore any other 
options. Just the binaries would help, once y'all decide how to name/specify 
them.

10.4 and 10.5 users who have PPC machines worth keeping might well have to 
consider gcc cxx11options, if those systems are to have any path forward to 
newer software. Jeremy has discussed this on a recent gtk3 ticket. It would not 
be expected to be part of the standard MacPorts process, as there is already 
plenty to do. A shadow repository for certain selected ports on these systems, 
such as the ones I've been building these past few months, would be the most 
likely way this would be implemented I think

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham Webuse]

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

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

>> 
>> 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 for sure they would not 
be accepted. 

thanks for the clarification. 


Ken

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

> 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 increased frequency of releases (i.e. yearly), vs. 
> every two or three years as in the beforetime.


I for one am very happy that patches are accepted for older systems, unlike 
homebrew and fink. And based on the hoopla when osxfuse wouldn't build on 10.6, 
I think I'm not the only one... I certainly don't expect anyone to spend time 
to work on these fixes, but I'm happy the fixes are accepted (and usually 
improved :>). My fixes aren't always the elegant solutions, and I'm always very 
happy to learn the better way.

Just so people realize, though -- with relatively modest changes, and with 
Jeremy's libc++ update to Snow Leopard, there are almost no ports that I can't 
install on SL so far. 

glfw on SL is pegged at the last version.
qt5 is ugly - I'm hoping to help out / find a way with a qt5.3 or qt5.4 version 
- but there aren't many ports that require qt5 yet anyway.
That's about it.

In fact a very large number of ports install all the way back to Tiger without 
any problem at all. 

So although of course the future has to be and always will be the focus, I hope 
that supporting backwards is not considered a total waste of time, if it 
doesn't take much or any effort other than tweaking and committing a patch. 

I take great satisfaction in keeping these older machines out of the landfill 
and doing useful things, and MacPorts is a big part of that.

Thanks to all!

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 
> (https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632).
>  My first question is regarding the procedure for failed builds: what is it 
> expected that I as the maintainer should do in this case? Should I notify 
> upstream and so maybe we could come up with a patch? Something else?
> 
> After that mail I got dozens of mails today from the buildbot regarding other 
> unrelated packages, many just a few seconds or minutes apart. Is this 
> expected or was there a glitch? I don't get why I'm getting mails for 
> packages that I didn't change or maintain.
> 
> Maybe what I am asking is explained somewhere in the documentation, but 
> honestly I couldn't find it. I may be looking at the wrong place.



Hmmm. I get the same error today:

:info:build /opt/local/bin/clang-mp-3.7  -pipe -Os -arch x86_64  
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o 
mutt_dotlock mutt_dotlock.o strndup.o strnlen.o wcscasecmp.o regex.o 
:info:build Undefined symbols for architecture x86_64:
:info:build   "_safe_malloc", referenced from:
:info:build   _strndup in strndup.o
:info:build ld: symbol(s) not found for architecture x86_64


I see he recently added it:

2016-06-04 11:32 -0700  Kevin McCarthy    (39639dc7e9e7)

* sidebar.c: Fix sidebar check_sec.sh warnings.

Use safe_malloc, FREE, and the safe_strcat functions.



==

and it seems to be defined here:
neomutt-20160916/rfc822.c


#if HAVE_CONFIG_H
# include "config.h"
#endif

#include 
#include 

#ifndef TESTING
#include "mutt.h"
#else
#define safe_strdup strdup
#define safe_malloc malloc
#define FREE(x) safe_free(x)
#define strfcpy(a,b,c) {if (c) {strncpy(a,b,c);a[c-1]=0;}}
#define LONG_STRING 1024
#include "rfc822.h"
#endif


and so I thought if I defined TESTING in config.h that might work -- 

/* config.h.  Generated from config.h.in by configure.  */
/* config.h.in.  Generated from configure.ac by autoheader.  */

#define TESTING 1

but it generate other errors.

Does this build for you?

Ken






___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 it 
on - a vanilla 10.6 system (my 10.6 systems are LibCxxOnOlderSystems now, with 
clang-3.7). 

So my choice is to let it use the existing default compiler and build a 
somewhat impaired but usable command-line only version, or force a compiler 
install (clang-3.4 works, maybe 3.3, clang 3.7 would be best), and get the 
really much better racing-stripes GUI version. The compiler would be installed 
precompiled on a vanilla 10.6 system. (LibCxx... systems already have 
clang-3.7, and so don't have this problem).

I'm tempted to force the compiler install, and if so it might as well be to 
clang-3.7.

Is this the "MacPorts" way?

Thanks,

ken

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[Ken Cunningham]

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 bump for MacOSX I've seen in a 
very long time.

At $0.50 (canadian) per GB, I put them in most of my systems -- even a 120GB 
version in my Beige G3 running MacOS 9.2.2. Now that is something to see!

Ken



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

review requested - hatari 1.9

[Ken Cunningham]

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 code to run on all known versions of python from 10.4 to now.

hatari 1.9

https://trac.macports.org/ticket/52212


at your convenience.

thanks,

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 that gets things messed up sometimes.

Anyone been down this path? Could always install the desktop’s tools and then 
hide them I suppose ...

Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

> 
> 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 indeed! I'll use that as a template & 
reference.

Thanks!

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Libpointing

[Ken Cunningham]

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 macports gurus can write a proper makefile for this, and 
replace the one that is in the port.

Or maybe I'm missing something simple that can be done to fix the Makefile that 
is there.

Best,

Ken



On 2016-09-13, at 8:02 AM, Izzat Mukhanov wrote:

> Hello,
> 
> Could you please take a look at the ticket 
> https://trac.macports.org/ticket/51737,
> 
> Regards,
> Izzat
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 application (I know what to do with that part of it), and 
a collection of python scripts, with a small executable that provides the 
command-line version of the port. The command-line version is designed to be 
run from this folder, as it calls folder-local python scripts.

To make it install as a command line app, I could xinstall the relevant parts 
of the build folder into ${prefix}/libexec/sshuttle, and then use a system call 
to symlink the main binary  back into

${prefix}/bin

Is that the recommended way to manage a port like this?

Thanks,

Ken





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

> 
> 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 that upstream for them to fix someday.

Although I'd still like to know how to adjust the $PATH, if you feel so 
inclined one day -- promise to use my powers for good and not for evil ...

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

> 
> 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 configuration 
script in the port I think. Maybe I can get it that way.

K


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 ${prefix}/bin/python2.7 at the head 
of the $PATH temporarily...

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 FindPythonInterp to find python. 


If I ensure "sudo port select python python27" and then build, all goes well. 
if I have python35 selected, the build fails, on SL and on El Cap.

I've pulled my hair out trying to find a portfile command that will force it to 
build with python27 even if the user has previously selected python35.

Here's what I've tried so far, none of which have worked to override the user's 
set python. I know I'm missing something simple thanks.

Ken




# port builds with python27 but not 3.5

#configure.python   ${prefix}/bin/python2.7

#build.env-append  PYTHON=${prefix}/bin/python2.7
#build.env-append  PYTHONEXECUTABLE=${prefix}/bin/python2.7
#build.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
#build.env-append  PYTHON_VERSION_MAJOR=2
#build.env-append  PYTHON_VERSION_MINOR=7


#configure.env-append  PYTHON=${prefix}/bin/python2.7
#configure.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
#configure.env-append  PYTHON_VERSION_MAJOR=2
#configure.env-append  PYTHON_VERSION_MINOR=7


#configure.args-append  PYTHON_VERSION_MAJOR=2
#configure.args-append  PYTHON_VERSION_MINOR=7


but no matter, I get 

:info:configure -- Found PythonInterp: /opt/local/bin/python (found version 
"3.5.2") 

and the build fails, unless I "sudo port select python python27" first.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Do I want subports?

[Ken Cunningham]

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 little GUI (that just edits a simple config file with text
lines) is compatible with gtk1 or gtk2 has no reason to be any special
architecture (x86-64 would be just fine, if you have the gtk tree built
that way).

I don't want to make people reinstall their whole gtk tree as universal for
no reason... on Snow Leopard (building from source) this takes half a day.
(OK, not quite -- but a long time).

Is this a role for subports, with the emulator forced to i386, but the gui
left to be whatever?

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 with)…

This website reference says -Os and -O2 are identical:

>

Haven’t yet benchmarked the differences between O2 and O3 within it, tho.

Of course, Jeremy would know all...

K


> On Sep 5, 2016, at 5:32 PM, Brandon Allbery  wrote:
> 
> 
> On Mon, Sep 5, 2016 at 8:10 PM, Fred Wright  > wrote:
> But when they switched to Intel, they also switched
> to -O2.  This allowed them to inflate the performance benefit of the
> architecture switch. :-)
> 
> ...as long as -O2 worked. Experience from FreeBSD and from early MacPorts 
> experiments with -O2 is that it took -O2 a long time to actually generate 
> correct code in a majority of cases.
> That said, it might be worth looking at again --- but, -O2 reportedly still 
> causes occasional problems for some programs, so be ready to bail back to -Os.
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com   
> ballb...@sinenomine.net 
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

> 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 might 
be (slowly) learning!

Because that is exactly what I did.

Ken

So here's what I have so far, to see how this is going for a newbie, moving 
from hacking makefiles, to hacking portfiles, to actually writing portfiles.
I think I could have picked an easier one than BasiliskII for my first go 
'round, but it works, and I'm into the fine tuning now...
compiler options, variants, active variant requirements ... 
now I need to figure out how to customize the "make" to "make XYZ".

I'm sure there are many ways this is not right there is a lot of 
information in the macports website for portfile writing to absorb..
-

# $Id: Portfile 135117 2015-04-15 19:51:30Z ryandes...@macports.org $

PortSystem  1.0
PortGroup   github 1.0
PortGroup   active_variants 1.1
github.setupcebix macemu 
1bf6f4d64023851e5de17c7d3090db99c7671c04
version 20160829
namebasiliskII
categories  emulators
license GPL-2+
platforms   darwin
maintainers gmail.com:ken-cunningham-webuse openmaintainer
description Opensource 68k Mac emulator.

long_description \
Longstanding 68K Macintosh emulator. You will need an appropriate Macintosh 
ROM image and a copy of Mac OS (0.x thru 7.5 for Classic emulation, 7.x or 
8.0/8.1 for Mac II emulation).  The default "jit" variant enables the 
Just-In-Time compiler, which is 32bit only. This may be faster on your system. 
It will require the dependent libraries to be built universal. Slirp networking 
is also 32bit-only at present. You can try a build without JIT or slirp, and 
this will generate a native build for your system (usually 64bit).

homepagehttp://basilisk.cebix.net/
checksums   md5 f289deebce6e528bc913fad0375752df

# --- DEPENDENCIES -

depends_lib port:libsdl \
port:gtk1

#consider how to find out if any other ports already installed are required by 
this port

# --- AUTOCONF -
worksrcdir  ${distname}/BasiliskII/src/Unix
use_autoconfyes

#this seems to be a funny command -- is there a more elegant way? this is a 
custom autogen.sh script
autoconf.cmdNO_CONFIGURE=1 `port work 
BasiliskII`/${worksrcdir}/autogen.sh

# --- COMPILER CHOICE -

# a bit complicated

# I confirmed  build with clang-3.7 (x86_64 and i386) and gcc-4.0 (can build 
i386 only)
# should therefore build with macports apple-gcc40
# confirmed not to build correctly with gcc-42
# clang < 500 means clang 3.3 or earlier

#compiler.whitelist macports-clang-3.7 gcc-4.0 apple-gcc40
#compiler.whitelist {clang > 500} gcc-4.0 apple-gcc40

compiler.blacklist-append   {clang < 500} macports-clang-2.9 macports-clang-3.0 
macports-clang-3.1 macports-clang-3.2 macports-clang-3.3
compiler.blacklist-append   {*gcc-4.[1-9]} {*gcc-3*}

# --- CONFIGURATION -
# no idea if this is the best optimization we can do -- direct from the gcc 
makefile

configure.cppflags  -g -O2
configure.cxxflags  -g -O2

configure.args  --without-esd --enable-sdl-video --enable-sdl-audio 
--disable-vosf


# --- VARIANTS -
# the default build builds the executable and installs it in ${prefix}/bin
# have to learn how to build the BasiliskII_App and move it into directory 
instead





# --- VARIANTS -

#building universal is not sensible for this port
universal_variant   no


# jit variant enables the JIT compiler and also slirp networking, but it could 
be slower than x86_64
# so allow people to turn it off if they want to 

default_variants +jit

variant jit description {JIT compiler is supported on arch i386 only, and also 
allows slirp which is i386-only} {
supported_archs i386
configure.args-append   --enable-jit-compiler

# make sure the dependent libraries are installed +universal, or this 
won't link
# could be just require i386 if machine arch is i386, and universal on 
x86_64 -- but that's just too complicated
# https://trac.macports.org/wiki/PortfileRecipes#gcc
require_active_variants libsdl universal
require_active_variants gtk1 universal
}

variant slirp description {Slirp networking is supported on arch i386 only. } {
supported_archs i386

require_active_variants libsdl universal

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

[Ken Cunningham]

> 
> 
> 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 (fairly quickly) without the JIT, but enabling 
the JIT crashes it (no surprise).

That will make the portfile much much easier to finish.

Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 BasiliskII portfile. I use this software often 
enough to care about it being up to date, but it has a few idiosyncracies.

Indeed I have the new portfile working to the latest github commits, BUT 
because of the current BasiliskII JIT compiler internals, it requires gcc-4.0 
only (I'm hoping that apple-gcc40 will build it on newer OSs once I get this 
working here), and it builds if it's compiled only with architecture i386. 

The x64_86 build runs into troubles with errors like this in their bitshifting 
/ bitblitting routines:

./../CrossPlatform/video_blit.h:131: error: integer constant is too large for 
‘unsigned long’ type
./../CrossPlatform/video_blit.h:131: error: integer constant is too large for 
‘unsigned long’ type

I was initially led to believe this was due to libSDL's architecture not being 
i386, but this is apparently not right. It's a 32bit/64bit thing.

Clearly upstream needs to fix this someday, but it's been like this for years. 
Everyone just builds it i386 and leaves it at that.

My machine, like almost everyone's, builds x86_64 and optionally i386. Even 
with +universal the build fails, however, when the x86_64 arch runs into the 
above error.

Clang does build it universal, but then the JIT fails due to the assembly 
language being i386 specific. So for now at least, it's gcc-4.0/i386 only if 
you want the JIT.

I can get the port to build and work just fine with: 

sudo port install basiliskII build_arch=i386

but I can't seem to find a way to specify this in the portfile (ie disable the 
x86_64 build and build only the i386 build). 

I dug through the website to see if I could find the appropriate portfile 
command and tried things like 
build.args  arch=i386
but that did not do the same thing as the command line option.

Thoughts? 

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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?

[Ken Cunningham]

Thanks for the info. I realize it's a small audience, and I'm happy to help, 
and in fact, don't mind plugging away at it when I have some time. No wonder 
the OP had trouble though. The toolchain blew up with the last updates to 
cctools and ld64, and the current instructions and state of things don't appear 
(to me) to be able to work. 

But I believe have it fixed now, I think, with one small change in the 
instructions,  and one small change in the ld64 portfile.

I was unable to resuscitate the toolchain after it pulled in ld64 +llvm34, and 
ultimately I had to uninstall the toolchain completely and start over.

The current LibCxxOnOlderSystems instructions are mixed between +llvm37 and 
+llvm38. You can't use +llvm37 or clang-3.7 options because they no longer 
exist in cctools or ld64, so +llvm34 will get pulled back in instead.

The install goes OK if you ignore all the references to +llvm37 or clang-3.7, 
and just insert +llvm38 or clang-3.8 instead.


HOWEVER you can't build ld64 against +llvm38 due to errors in math.h (as Jeremy 
pointed out).

sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_136 
-ld64_236


As per:

<http://clang-developers.42468.n3.nabble.com/problems-building-libcxx-td2353619.html>

These math errors appear to be fixed on 10.6 by adding this line in the ld64 
portfile -- 

configure.cppflags-append -I${workpath}/dyld-${dyld_version}/include
+configure.cppflags-append -U__STRICT_ANSI__

And then it all installs 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 from the new ld64 portfile.
>> 
>> and so when the porfile saw my requested +llvm37, it saw that as no llvm 
>> variant, and defaulted to llvm34. And now my toolchain is looking pretty 
>> inoperable.
>> 
>> there isn't an llm37 option in the ld64 portfile any longer.
>> 
>> I either have to add one -- or -- reinstall everything
>> 
>> but the <https://trac.macports.org/wiki/LibcxxOnOlderSystems> instructions 
>> currently have a mixture of clang-3.7 references and llvm38 references.
> 
> That's partially because it was written when 3.7 made sense (ok, it
> was probably earlier, when 3.5 or 3.6 was there), then 3.8 was
> released, but buggy, so some instructions reverted back to 3.7 ...
> 
>> I thought 3.8 was not yet workable, and so we were to stick with 3.7 -- 
>> maybe this is in transition?
> 
> Probably. Your feedback might help though.
> 
>> Looks like I need to let this all settle down in the portfile evolution for 
>> a bit, and come back in a few days :>
> 
> Jeremy was cleaning up some of these files recently and it's quite
> likely that not all of the changes were heavily tested on 10.5 and
> 10.6.
> 
> As an example, a recently discovered problem on 10.5 has just been
> fixed and more changes have been applied just now. It makes sense to
> open a new ticket for a problem like the one you mentioned. (Actually,
> it also makes sense to upload crash reports and other problems to a
> ticket in Trac. Trac can easily handle a 2 MB file that pastebin is
> refusing.)
> 
> The setup for libc++ has a very small audience / a very small pool of
> testers. Until we set up new build slaves and attract more users,
> problems are to be expected. (Even then it will still be a problem
> because most developers use the latest OS, so there are very often
> very few people able to help.) Most support for old OSes is there
> because those OSes used to be "up-to-date" some time back and
> developers made sure everything was working (at least until new
> software came up that required C++11). The libc++ support came later
> and is constantly evolving due to releases of newer compilers.
> 
> Mojca

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

"Default" portgroup?

[Ken Cunningham]

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 
libsnowleopardfixes code to 10.6 systems, or adding -stdlib=libc++ to the CXX 
directives on all ports with libc++ added, or other things that I haven't 
considered yet..

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Updating tk +quartz failed on Snow Leopard

[Ken Cunningham]

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 something like this:
> 
> #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
> 
> [do someStuff:here andHere];
> 
> #endif
> 
> and see if it builds on 10.6? If so, send me a patch and I'll test it on 
> 10.11 and commit if it works. I have no access to 10.6.
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev


It looks like it works as expected. There are different ways to do the same 
thing, but the easy-to-read, non-underscore version of these tests uses 
 rather than the newer but more complicated 
, and worked like this:

Testing out the following code on snow leopard:

--
#include 
#include 

#define MY_CURRENT_OS   MAC_OS_X_VERSION_MAX_ALLOWED

int main() {

printf("%d\n", MAC_OS_X_VERSION_MAX_ALLOWED); 
printf("%d\n", MAC_OS_X_VERSION_MIN_REQUIRED);



#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
printf("This code will only be seen and compiled Lion or greater!\n");
// and more
#endif

#if MAC_OS_X_VERSION_MAX_ALLOWED == 1060
printf("This code is only seen and compiled on Snow Leopard\n");
// and more
#endif

#if MAC_OS_X_VERSION_MAX_ALLOWED <= 1050
printf("This code is only seen and compiled on Leopard or Older\n");
// and more

#endif


#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
printf("This MIN version specifies code that is only seen and compiled 
on Snow Leopard or earlier\n");
// and more
#endif


return 0;
}

--

produces the following output:

KensMacBookPro:compiler tests cunningh$ clang test.c -o test
KensMacBookPro:compiler tests cunningh$ ./test
1060
1060
This code is only seen and compiled on Snow Leopard
This MIN version specifies code that is only seen and compiled on Snow Leopard 
or earlier

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

>> 
>> 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 generating patches for the ports.
> 
> Starting to sound more like a "just works" scenario. Will investigate.
> 


Yeah - that idea certainly works. Adding this in the portfile:

configure.ldflags-append "-lsnowleopardfixes"
configure.cxxflags-append -include ${prefix}/include/libsnowleopardfixes.h


and lnav builds without touching a single line of code in the port.

Just wrap that up in a Darwin 10 block, and it would appear to be done.

I'll build a Makefile and a portfile for this, and perhaps others can try it 
out if they wish to.

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

> 
> 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 generating patches for the ports.

Starting to sound more like a "just works" scenario. Will investigate.


On my own system (Josh and Ryan - please don't listen for a moment) I added a 
link to the snowleopardfixes library directly into portconfigure.tcl so it 
happens with every port (along with the -stdlib=libc++ because of the libc++ 
upgrade made here), and I also made a new file in /usr/local/include/strings.h 
that calls the system strings.h then adds in the declarations.

So the whole thing works transparently for C code. Still trying to figure out 
if I can do that declaration trick for c++ code.

but that is certainly not ready for the wild.

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

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.cunningham.web...@gmail.com> wrote:
>> 
>> 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.
> 
> I believe `install_name_tool -id /opt/local/lib/libsnowleopardfixes.a.dylib 
> /opt/local/lib/libsnowleopardfixes.a.dylib` would have worked also.
> 
> vq

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

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 getline.c -current_version 1.0 
>>> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
>> 
>> You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here.
>> 
>>> configure:3663: ./conftest
>>> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>>> Referenced from: 
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>>> Reason: image not found
>>> ./configure: line 3665: 50401 Trace/BPT trap  
>>> ./conftest$ac_cv_exeext
>>> configure:3667: $? = 133
>>> configure:3674: error: in 
>>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
>>> configure:3676: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>> 
>> This check just tests whether you can run compiled programs. Because
>> your library does not have a correct install name it is not found by the
>> loader, which causes the test program to fail.
>> 
>> The configure script just happens to assume that you might be
>> cross-compiling if you cannot run the generated binaries.
>> 
>> -- 
>> Clemens
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

thanks,

I thought of that, but 

sudo install_name_tool -add_rpath /opt/local/lib 
/opt/local/lib/libsnowleopardfixes.a.dylib

didn't solve the issue. Sorry I left that step out.

then I went big-gun and set the DYLIB_FALLBACK_LIBRARY_PATH

but that didn't work either.

I'll keep plugging.

As Ryan says, if the upstream would just improve their use of glib a bit and 
test for getline, then we wouldn't need to go through all this nonsense. But it 
is very very common that they don't check for getline.

Ken




On 2016-08-23, at 10:16 AM, Clemens Lang wrote:

> Hi,
> 
> On Tue, Aug 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.
> 
>> configure:3663: ./conftest
>> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>>  Referenced from: 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>>  Reason: image not found
>> ./configure: line 3665: 50401 Trace/BPT trap  ./conftest$ac_cv_exeext
>> configure:3667: $? = 133
>> configure:3674: error: in 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
>> configure:3676: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
> 
> This check just tests whether you can run compiled programs. Because
> your library does not have a correct install name it is not found by the
> loader, which causes the test program to fail.
> 
> The configure script just happens to assume that you might be
> cross-compiling if you cannot run the generated binaries.
> 
> -- 
> Clemens

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

> 
> 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 ./libsnowleopardfixes.a.dylib /opt/local/lib/libsnowleopardfixes.a.dylib
sudo ln -s /opt/local/lib/libsnowleopardfixes.a.dylib 
/opt/local/lib/libsnowleopardfixes.dylib

but something a bit odd happens during the configure phase of lnav. With the 
static library, it all went fine through to the build. But with the dyllib, all 
goes well and the dylib seems to be found (and basically ignored) until I get 
this funny error during the check when configure checks for "cross compiling"...

Open to your thoughts - perhaps configure needs libsnowleopardfixes to be a 
universal dylib to function during this phase?

Easy enough to try. I don't exactly know what configure is checking for during 
the cross-compile stage of testing

Ken



--- lnav configure.log part 
configure:3484: $? = 1
configure:3504: checking whether the C++ compiler works
configure:3526: /opt/local/bin/clang++-mp-3.7 -pipe -Os -arch x86_64 
-stdlib=libc++ -I/opt/local/include -I/opt/local/include -I/usr/local/include 
-I/usr/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 
-stdlib=libc++ -lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib 
-L/usr/lib conftest.cpp  >&5
configure:3530: $? = 0
configure:3578: result: yes
configure:3581: checking for C++ compiler default output file name
configure:3583: result: a.out
configure:3589: checking for suffix of executables
configure:3596: /opt/local/bin/clang++-mp-3.7 -o conftest -pipe -Os -arch 
x86_64 -stdlib=libc++ -I/opt/local/include -I/opt/local/include 
-I/usr/local/include -I/usr/include -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib -L/usr/lib conftest.cpp  
>&5
configure:3600: $? = 0
configure:3622: result: 
configure:3644: checking whether we are cross compiling
configure:3652: /opt/local/bin/clang++-mp-3.7 -o conftest -pipe -Os -arch 
x86_64 -stdlib=libc++ -I/opt/local/include -I/opt/local/include 
-I/usr/local/include -I/usr/include -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib -L/usr/lib conftest.cpp  
>&5
configure:3656: $? = 0
configure:3663: ./conftest
dyld: Library not loaded: libsnowleopardfixes.a.dylib
  Referenced from: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
  Reason: image not found
./configure: line 3665: 50401 Trace/BPT trap  ./conftest$ac_cv_exeext
configure:3667: $? = 133
configure:3674: error: in 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
configure:3676: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.

-- 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

how about a 'snowleopardfixes' library port?

[Ken Cunningham]

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 built a static library with a 
getline replacement in it, called it 'libsnowleopardfixes.a', put it in 
/opt/local/lib, and added it to the linked libraries on lnav. 

Then, it required only a single line of code to be added to the file where it 
fails (in this case, common_executor.cc); because lnav is c++ code, it required 
this version:

"extern "C" ssize_t getline(char **lineptr, size_t *n, FILE *stream);"

and to have the library added to the ldflags, and the port built and ran 
without trouble. 

Perhaps there is somewhere more elegant I could have put the definition, but it 
seemed to be required only in this one file.

This seems to be a contender for a fairly easy way to solve a lot of troubles 
with these missing snowleopard functions...

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

Right to the top... 

Thanks for the feedback. You know 10x more about this than I do, no 
argument at all there.

Noted...always a possible downside to trying things.

As you can tell, I'm trying to poke around to find a reasonably elegant way to 
avoid forcing a (basically unnecessary) update to what might be hundreds or 
thousands of portfiles (or worse, perhaps, trying to get updates pushed through 
to all the ports they represent) for something the ports obviously feel the 
system should be doing itself (which is automatically linking  in the correct 
stdlib, which we have monkeyed 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 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 
>> -stdlib=${configure.cxx_stdlib}
>>   append_to_environment_value configure OBJCXXFLAGS 
>> -stdlib=${configure.cxx_stdlib}
>>   #kenhack
>>   append_to_environment_value configure "LDFLAGS"  
>> -stdlib=${configure.cxx_stdlib}
>>   }
>> 
>> appears to fix the missing link reference to the standard c++ lib, and as 
>> far as I can see would apply to all ports.
>> 
>> It works well here, so far, to fix the missing libc++ link without modifying 
>> the portfile.
>> 
>> Will test further to see if it causes any unforeseen troubles on my other 
>> macports systems running different OS versions, but this would not appear 
>> likely to cause trouble to me...
> 
> The trouble is that LDFLAGS is not specific to C++, it's used when linking 
> everything. At best, the link command will ignore -stdlib, at worst, it may 
> fail when given an option it doesn't recognise. (This is much the same reason 
> why it checks that configure.cxx is clang++ as well.)
> 
> - Josh

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 
-stdlib=${configure.cxx_stdlib}
   append_to_environment_value configure OBJCXXFLAGS 
-stdlib=${configure.cxx_stdlib}
   #kenhack
   append_to_environment_value configure "LDFLAGS"  
-stdlib=${configure.cxx_stdlib}
   }

appears to fix the missing link reference to the standard c++ lib, and as far 
as I can see would apply to all ports.

It works well here, so far, to fix the missing libc++ link without modifying 
the portfile.

Will test further to see if it causes any unforeseen troubles on my other 
macports systems running different OS versions, but this would not appear 
likely to cause trouble to me...

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

Thanks for the rescue :>

That looks like what I was after. It's easy to spot in the portfile, clear, and 
can be very specific for snowleopard, or generalized up to the 10.8 & earlier 
if the fixes work all the way up to there with a simple, easily recognized 
change.

Re: overly specific -- Indeed, I'm trying hard to stay well clear of the other 
systems to avoid any chance of causing unforeseen trouble - supporting snow 
leopard is not on many people's radar perhaps, and I certainly don't want to 
trigger some Portfile frustrations that triggers support to drop completely in 
the 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 seemed so handy for what I wanted to do.
>> 
>> Damn. Bad start to this thread. Let me try again another day.
> 
> No need:
> 
>   if {${os.platform} eq "darwin" && ${os.major} <= 10
>   && ${configure.cxx_stdlib} eq "libc++"} {
>   # Snow Leopard and earlier
>   }
> 
> Tiger is 8, Leopard 9, etc.
> 
> As I mentioned in one of the tickets you opened, I don't see a need to
> check the OS unless the fix actually breaks things on newer OSes,
> although I guess there's something to be said for being as specific as
> possible.
> 
> vq
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


and for 10.8 or lower with libcxx, use this:

# Mountain Lion or older with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} <= 8} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 



Ken

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

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 propose for a specific snowleopard with libcxx fix, use this:

# Snow Leopard with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} == 6} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


and for 10.9 or lower with libcxx, use this:

# Mountain Lion or older with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} <= 9} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


To change from one to the other requires changing only two characters in the 
MINOR test, and it seems suitably specific, concise, and clear.

Feedback or thoughts?

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Determine before installation whether a port can be installed

[Ken Cunningham]

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 'distributions' idea in that ticket I opened 
a few weeks ago.

The only extra part of this that I was hoping for would the ability to peek 
back in the port file history and find (and install) the last version of a port 
file (apache2, say) that was able to be installed on a given system (like SL). 

This ability would solve a lot of troubles for older systems, although there 
could be the same dependencies issues that this idea will generate as well, 
perhaps.

As macports moves forward, the caboose of which machines are left behind will 
continue to move forward as well. But there are working portfiles back there 
that are still good...

My $0.02.

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham]

Thanks for taking the time to give such a detailed answer. 

I can see what I did, after reading your note and ticket -- I ran into the 
libLTO bug as well, but instead of seeing it as a bug, I thought I had messed 
up something in the tool configuration by mixing clang/ld64 versions (and I 
guess sorta did).

I did manage to work around it and get a functional clang-3.8 system, and a 
functional ld64 (and deactivated clang-3.7).

Maybe I'll leave all that alone for a while now :>

I see Jeremy is sorting all this out so others don't fall into this trap.

Ken





On 2016-07-27, at 7:26 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 to upgrade the compiler chain from clang-3.7 to
>> clang-3.8, I'd like to have a slightly better understanding of how these 
>> tools
>> fit together.
> 
> This is a bug and not intended behavior. I have created a new ticket #51929 
> for
> this, including a description of what is wrong.[0]
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

llvm / clang / cctools / ld64 version consistency question

[Ken Cunningham]

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 understanding of how these tools 
fit together.

There is a port select mechanism for clang, and a port select mechanism for 
llvm. But would it be fair to say you would always do both of them together, ie 
if you're switching to clang-3.8, you'll also need to switch to llvm-3.8? This 
seems pretty obvious, and I always do switch both when I do it. Should the port 
select mechanism just do that automatically for both if you ask it do it for 
one?

Also, cctools and ld64 also have a specific variant for each version of llvm, 
it appears from the following command.


sudo port -v -n upgrade --enforce-variants cctools -llvm33 -llvm34 +llvm37 
configure.compiler=macports-clang-3.7
sudo port -v upgrade --enforce-variants ld64 -llvm33 -llvm34 +llvm37 
configure.compiler=macports-clang-3.7

So is it also the case that if you're switching clang versions (and then llvm 
versions) you need to run commands like the following to bring your cctools and 
ld64 variants into sync?


And finally, for those of us who have installed libc++ on older systems, just 
to clarify that libc++ is a fixed entity, and it does not change or need to 
change with any of the above - build it once, install it, and leave it alone, 
basically?

Hope this question is clear. Thanks,

Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: portfile test for macosx 10.6.8 + libc++

[Ken Cunningham]

You are completely correct, of course - upstream fixes would be ideal, and much 
preferred over fixing the portfile to repair upstream deficiencies. Most ports 
that use configure already seem to get these things brought in from the GnuLib 
replacements, I've found.

But I suppose I'm torn between what is ideal and what is attainable. I don't 
see upstream being responsive to these requests - quite reasonably I guess. 
Better things to do than support 8+ year old hardware. Most of these fixes seem 
to be added in case-by-case by the individual portfile maintainers.

These ports are all working for me here. My goal is only to be helpful, and 
allow others to share the outcome of my efforts. 

But I can certainly blog the modifications somewhere and let those interested 
find it that way, rather than clutter up macports with it, if that is preferred.

Best,

Ken




On 2016-07-19, at 7: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.
>> 
>> I have found that almost any port I have tried to install can be installed 
>> on this system (so far), with minor surgery to replace a missing function or 
>> two (strnlen and getline being the two most common) and often replacing a 
>> few missing libraries or missing includes to fix errors during the build.
>> 
>> My goal would be to suggest minor mods to portfiles to allow others to do 
>> the same if they choose -- and perhaps to leverage this to similar systems 
>> (10.7 and 10.8 libc++) if it's easy to do so.
> 
> Those issues you mentioned don't sound like they should be conditionalized in 
> the portfile. If software wants to use functions like strnlen or getline 
> which are not on all systems, the software should check for the existence of 
> those functions in its configure script, and if not available, define and use 
> suitable alternatives. Missing libraries or includes similarly sound like 
> something that should affect all systems. If any conditionalizing needs to be 
> done, it should be done in the project's build system, not the MacPorts 
> portfile, since the problem is not unique to MacPorts.
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

portfile test for macosx 10.6.8 + libc++

[Ken Cunningham]

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 think that same test should apply also to 10.7 with libc++, in most 
cases, ie lump them together?

Thanks,

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev