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. Whe
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 sta
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
___
macport
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
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@… |
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 mor
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
_
Thanks, all — good advice.
K
> On Oct 14, 2016, at 8:14 AM, Joshua Root wrote:
>
> On 2016-10-15 01:50 , Ken Cunningham wrote:
>>
>> I notice mdworker seems to go nuts during these long builds, often appearing
>> to soak up lots of cycles. I assume it’s tr
> On Oct 14, 2016, at 7:30 AM, Ken Cunningham
> 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
Some advice appreciated ...
long compiles can take hours
i can ssh into the machine and get it started
sudo port -v install gcc48 gcc5 gcc6 gcc7
that, for example, might take several days to finish (if it does finish)
then I control-Z to pause it, and "bg" to throw it into the background
the
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
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 suppor
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 acc
s.llvm.org/D21803 as that might be quite useful for your needs.
> If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.
>
> Thanks,
> Jeremy
>
>
>> On Oct 8, 2016, at 23:06, Ken Cunningham
>> wrote:
>>
>>
>> On 201
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
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
at 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
>> wrote:
>>
>> I think this one looks ready for prime time.
>>
>> https://trac.macports.org/ticket/52188
>
> I had bee
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 need
>
> 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.
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
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
>> wrote:
>>
>> I think this one looks ready for prime time.
>>
>> https://tr
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
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
mac
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
>
> 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
>>
>> 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 fo
> 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 increas
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
>
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 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
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 cod
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 tha
>
> 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 i
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 macpo
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 app
>
> 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
>
> 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 c
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}/
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 FindPyth
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 littl
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 w
> 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 mi
>
>
> 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
>
> "supported_archs i386"
>
thanks. I couldn't seem to find that one anywhere, but now I see it's in a
different section of the portfile reference than I thought it would be.
> This is ludicrous. GCC 4.0 is a decade old.
I know. The JIT assembly uses some gcc-4.0 specific register assignment
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 B
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.
>>
>>
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
li
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 someth
>>
>> 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 g
>
> 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 generat
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
>> 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.
Best,
Ken
>>
>> On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote:
>>> clang -dynamiclib -std=gnu99 strnlen.c getli
i,
>
> 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.
>
> 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 ./libsnowleopardfi
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 bui
keyed 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=$
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
> wrote:
>
>> I just realized that MINOR is a qt4-mac specific global, not
>> a Macports global. And it seemed so handy for what I wan
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
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
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 p
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 'distrib
7, 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" whe
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
016-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
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 miss
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
67 matches
Mail list logo