On 11 Nov 2018, at 13:00, macports-users-requ...@lists.macports.org wrote:
> Message: 11
> Date: Sat, 10 Nov 2018 15:27:51 -0600
> From: Ryan Schmidt
> To: Dave Horsfall
> Cc: MacPorts Users
> Subject: Re: How Mojave-ready is MacPorts?
> Message-ID: <5035eaa0-bd67-48d0-aae3-57af03245...@macports
On 12 Nov 2018, at 22:32, Ryan Schmidt wrote:
> What we really want is a web site where this information can more easily be
> seen.
> I don't really want the public making massive numbers of http requests to the
> buildmaster (which is what the script would do)
I just want that every build rep
On 4 Feb 2019, at 13:00, macports-users-requ...@lists.macports.org wrote:
> Message: 5
> Date: Sun, 3 Feb 2019 20:24:48 -0800
> From: Al Varnell
> To: James Linder
> Cc: macports-users@lists.macports.org
> Subject: Re: browser recomendations
> Message-ID: <8d355b58-5608-452d-9dc8-216c6015a...@mac
On 5 Apr 2020, at 14:00, macports-users-requ...@lists.macports.org wrote:
> Message: 1
> Date: Sun, 5 Apr 2020 01:21:40 -0700
> From: Ken Cunningham
> To: macports-users@lists.macports.org
> Subject: Ubuntu 18.04.4 on older Apple hardware
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
Is it feasible to maintain an older lib to compile a certain port?
I wanted to update ngrep 1.45 (sourceforge) to 1.46 (github) and tried
compiling in a system that had an older version of libpcap, 1.7.4 (current is
1.8.1). It worked only without the patches. It's far from ideal, but it has no
On 31 Jan 2017, at 06:47, Michael wrote:
> Nope, /usr/bin. Which package installs script?
util-linux
Both should be there
port contents coreutils | grep stdb # bins are prefixed with g
port contents expect | grep unbuffer
On 31 Jan 2017, at 05:27, Michael wrote:
> So I wanted to linebuffer a program that is feeding into a pipe.
>
> Looking around with Google, I found two solutions:
> 1, unbuf
How can I override a local portfile without deleting it? I want to keep some
ports locally, for example, after I submitted a new, locally tested port that
made it in the repo, or when I want to keep an older portfile until I fully
tested the latest version of an application.
I already have a local repo — I'd like a port in the rsync tree to
exceptionally override the local one (higher preference) while keeping both in
place.
On 2 Feb 2017, at 14:31, Mojca Miklavec wrote:
> On 2 February 2017 at 09:17, db wrote:
>> How can I override a local po
On 2 Feb 2017, at 16:34, Mojca Miklavec wrote:
> If you only want to do it once, you can cd to the folder with the port
> that you want to use and run "sudo port ..." from there.
Hmm…no, I thought I could mark the ports' default priority/availability,
something like setrequested with leaves.
I
, Chris Jones wrote:
> Hi,
>
> On 02/02/17 16:16, db wrote:
>> On 2 Feb 2017, at 16:34, Mojca Miklavec wrote:
>>> If you only want to do it once, you can cd to the folder with the port
>>> that you want to use and run "sudo port ..." from there.
>
Could you please review this ticket? I submitted it 8 days ago.
(I already sent this message to the dev list, but got rejected since I'm not
subscribed there, oh well…).
On 6 Feb 2017, at 02:57, Ryan Schmidt wrote:
> If you are using a git checkout of the complete ports tree (like I am), then
> you have no use for the rsync tarball anymore.
Not yet, but I might give it a try. Any caveats worth mentioning or adding to
the guide?
Could you tell when a new port is listed at macports.org?
E.g., hstr has already been accepted but it doesn't show up.
https://www.macports.org/ports.php?by=name&substr=hstr
In that case, maybe that page could hint at github's macports repo for
searching.
On 6 Feb 2017, at 19:56, Mojca Miklavec wrote:
> On 6 February 2017 at 19:28, db wrote:
>> Could you tell when a new port is listed at macports.org?
>>
>> E.g., hstr has already been ac
Sometimes the README files from tarballs is better (re completeness/clarity)
than the installed documentation. Is there any way to include them by default?
Thanks for the reference. I think this snippet could be mentioned under `4.7.3.
Install Docs and Examples` in the guide, where there's already a placeholder
header.
On 11 Feb 2017, at 23:19, Ryan Schmidt wrote:
>
> On Feb 11, 2017, at 13:15, db wrote:
>
>> Sometimes t
How can I mark a port to not be upgraded by `port upgrade outdated`, for
example, one that has a bug in my system version?
atco wrote:
>>>
>>> You can try sudo port upgrade outdated and not
>>>
>>> or
>>>
>>> sudo port upgrade outdated and not and not rdependentof:
>>> (not sure of the exact syntax, here)
>>>
>>> To ignore a por
On 14 Feb 2017, at 23:08, Clemens Lang wrote:
> If this isn't sufficient, you can keep an old copy of the port in a local
> portfile repository [1], but please don't forget about that if you do it.
It is not, but a local portfile seems to also override a potential upgrade.
Any other ways? Shoul
use a git checkout. Or, how
do you manage/rollback a broken application while updating, say, 50+ ports? I'm
just curious.
On 17 Feb 2017, at 01:12, Ryan Schmidt wrote:
>
> On Feb 15, 2017, at 15:58, Clemens Lang wrote:
>
>> On Wed, Feb 15, 2017 at 09:27:25AM +0100, db wro
and MacPorts would be a
reasonable excuse for using it more often. What's your experience with it and
MacPorts? Could you mention any caveats for a use case like the above?
On 17 Feb 2017, at 21:54, Ryan Schmidt wrote:
>
> On Feb 17, 2017, at 10:13, db wrote:
>
>> I g
I submitted this one about a week ago.
I changed the source to git. Can I safely delete the rsync tarball and related
files at /opt/local/var/macports/sources/rsync.macports.org/ ?
I also upgraded to 2.4.1 using `port`. Are there any files remaining from it
that could/should be deleted? I noticed that this is still using rsync.
05:08, db wrote:
>
>> I changed the source to git. Can I safely delete the rsync tarball and
>> related files at /opt/local/var/macports/sources/rsync.macports.org/ ?
>
> Sure.
>
>
>> I also upgraded to 2.4.1 using `port`. Are there any files remaining from
On 27 Feb 2017, at 20:48, Ryan Schmidt wrote:
> What files are you referring to?
> Are you claiming that something new is using up 1GB of space?
Starting with 4.8 GB MacPorts prefix, I changed the source to using git and
upgraded to 2.4.1 via `port` — it went up to 5.9, from which I deleted .35
On 27 Feb 2017, at 20:48, Ryan Schmidt wrote:
> What files are you referring to?
> Are you claiming that something new is using up 1GB of space?
After a reboot I realised that the Finder got the folder size wrong and that
after deleting the rsync tarball I actually gained meager 150 MB.
In any
On 2 Mar 2017, at 01:21, Brandon Allbery wrote:
> In fact only one change is needed: you do some of the early steps on the
> origin system instead of all of it on the destination. I've used an adjusted
> version of that a few times to do migrations, including with Apple's
> Migration Assistant
Could someone take a look at this submission?
https://trac.macports.org/ticket/53591
On 24 Feb 2017, at 15:16, db wrote:
> I submitted this one about a week ago.
On 5 Mar 2017, at 01:58, Michael wrote:
> Ok, how?
>
> Is it as simple as "copy these files out of the git tree into the /opt tree"?
> And if so, will that "clean up" automatically the next time I do a selfupdate?
>
> Is there an environment variable I can set to say "Find the portfiles here,
Is there any way to enable verbose output _after_ entering shell mode with
`port`? I'd rather not use `port -v`, then I get it unnecessarily for all
commands.
Do you know of any means that I'm not aware of to make livecheck output its
result without -v?
On 6 Mar 2017, at 13:45, Ryan Schmidt wrote:
>
>> On Mar 6, 2017, at 03:46, db wrote:
>>
>> Is there any way to enable verbose output _after_ entering shell mode with
Try with emacs.
On 6 Mar 2017, at 14:47, Ryan Schmidt wrote:
> On Mar 6, 2017, at 07:44, db wrote:
>
>> Do you know of any means that I'm not aware of to make livecheck output its
>> result without -v?
>
>
> There doesn't seem to be any differen
I meant try with other ports, e.g., emacs
$ port livecheck emacs
$
$ port -v livecheck emacs
emacs seems to be up to date
Not all ports give the same output with livecheck without -v.
On 6 Mar 2017, at 14:54, Ryan Schmidt wrote:
> On Mar 6, 2017, at 07:53, db wrote:
>
>> Tr
I would expect some output without verbose flag like
$ port livecheck [port]
[port] seems to be up to date
Not worth a feature request, I guess.
On 6 Mar 2017, at 15:05, Ryan Schmidt wrote:
> On Mar 6, 2017, at 08:03, db wrote:
>>
>> I meant try with other ports, e.g., emac
On 6 Mar 2017, at 23:29, Geoff Down wrote:
> On Mon, Mar 6, 2017, at 09:51 PM, Daniel J. Luke wrote:
>> On Mar 6, 2017, at 4:44 PM, Geoff Down wrote:
What Mac OS X version are you on?
>>> 10.4.11 .That's also why I can't access Trac via Github.
>>
>> IIRC macports uses libcurl linked agains
I'm trying to port a client that comes with only a makefile, but fail to
destroot it, although it sort of does if I sudo manually. I attach the log.
https://github.com/tldr-pages/tldr-cpp-client/blob/master/Makefile
main.log
Description: Binary data
On 7 Mar 2017, at 17:29, Ryan Schmidt wrote:
> The Makefile does not support DESTDIR. Ideally, fix the Makefile to support
> DESTDIR and submit that to the developers.
MacPorts Guide links to
http://www.gnu.org/prep/standards/html_node/DESTDIR.html, where it states 'You
should not set the valu
On 7 Mar 2017, at 20:00, Ryan Schmidt wrote:
> That can be an acceptable workaround. Sometimes it has side effects. I don't
> know if it does with this port.
Can you give an example?
Something strange I found is that file copy fails silently, no log whatsoever,
pre- and post-destroot.
post-de
On 8 Mar 2017, at 01:10, Ryan Schmidt wrote:
>> On 7 Mar 2017, at 20:00, Ryan Schmidt wrote:
>>> That can be an acceptable workaround. Sometimes it has side effects. I
>>> don't know if it does with this port.
>
> In the destroot phase, you should not be attempting to modify anything
> outside
I use 10.8 (don't need/don't want to upgrade) and stumbled upon a couple of ports that require libc++.So I gave building from source a try in a vm following these instructions and soon encountered a couple of problems with python2_select (needed base updated) and xorg-libX11 (attached config.log),
On 24 Mar 2017, at 16:00, Rainer Müller wrote:
> A similar ticket had been filed before:
> https://trac.macports.org/ticket/52335
I don't see how that explains that 1.6.4_0 in one system is the binary from MP,
but this same version fails to compile in another identical system. OS X
10.8.5, Xcod
On 24 Mar 2017, at 19:23, Ryan Schmidt wrote:
> I agree that ticket describes the error you encountered. It was closed
> because nobody could explain it and the problem went away for the reporter.
> You could re-open it and add your new information to it.
Re-open #52335 while it's for different
On 24 Mar 2017, at 19:21, Ryan Schmidt wrote:
> Upgrading to a version of macOS with libc++ as default (10.9 and later) will
> probably make your MacPorts life easier, but it's up to you of course.
Despite the overall lower quality and usability of 10.9+, I don't see how,
since MP in 10.8 can b
chosen.
>
> Please do open a ticket with whatever relevant data you can provide.
>
>> On Mar 24, 2017, at 14:24, Ryan Schmidt wrote:
>>
>>
>> On Mar 24, 2017, at 14:48, db wrote:
>>
>>> On 24 Mar 2017, at 19:23, Ryan Schmidt wrote:
>>&g
On 24 Mar 2017, at 22:24, Ryan Schmidt wrote:
>> Should I expect to encounter problems when switching to building from source
>> with libc++ for the same ports whose binaries work fine with libstdc++?
>
> Certainly; libc++ on 10.8 is a nonstandard configuration that most MacPorts
> developers
On 27 Mar 2017, at 11:12, Mojca Miklavec wrote:
> Dealbreaker:
>https://trac.macports.org/ticket/50448
Thanks for pointing that out. I skimmed through it.
What's the actual state re libc++ binaries for <10.9?
Is dropping support for <10.9 something MP team is considering?
As a 10.8-user, M
On 28 Mar 2017, at 13:15, Rainer Müller wrote:
> The support in base is missing to differentiate between binary archives
> with a different cxx_stdlib. That is required to provide an upgrade path
> for existing installations.
May I assume that that won't happen in the foreseeable future and start
On 28 Mar 2017, at 17:31, "Daniel J. Luke" wrote:
> On Mar 28, 2017, at 9:55 AM, db wrote:
>> Is there any MP official notice of support?
> It's right there on https://www.macports.org
That is not. And one thing is targeting mainly systems still supported by
Apple,
On 28 Mar 2017, at 17:42, db wrote:
> On 28 Mar 2017, at 17:31, "Daniel J. Luke" wrote:
>> On Mar 28, 2017, at 9:55 AM, db wrote:
>>> Is there any MP official notice of support?
>> It's right there on https://www.macports.org
>
> That is not. An
On 1 Apr 2017, at 17:24, Ken Cunningham wrote:
> I am not (presently at least) on the macports team, but I have been building
> all software from source with libc++ for over a year now on 10.6.8 with
> outstanding success. I works extremely well for me.
> ...
> Not everything works --- the only
On 3 Apr 2017, at 18:09, Mojca Miklavec wrote:
> Basically yes. You could follow point 3 of
> https://trac.macports.org/wiki/Migration
Is the script from 3.e. relevant if no particular variants were installed? I
ask because I probably won't automate the whole process as I might have to
check s
I set MP_EDITOR but it doesn't seem to work on base 2.4.1. VISUAL, second var
MP checks according to the guide, does though.
On 4 Apr 2017, at 11:18, Rainer Müller wrote:
> How did you test this? This works fine for me:
> $ export MP_EDITOR=less
> $ port edit zlib
export VISUAL=/opt/local/bin/vim works
export MP_EDITOR=/opt/local/bin/vim doesn't
On 4 Apr 2017, at 09:44, Barrie Stott wrote:
> 2. I would like to be able to take a requested port and find the tree of
> ports that would need to be installed before this port.
http://apple.stackexchange.com/questions/26921/installed-macports-packages-sizes/240638#240638
On 4 Apr 2017, at 11:21, db wrote:
> On 4 Apr 2017, at 11:18, Rainer Müller wrote:
>> How did you test this? This works fine for me:
>> $ export MP_EDITOR=less
>> $ port edit zlib
> export VISUAL=/opt/local/bin/vim works
> export MP_EDITOR=/opt/local/bin/vim doesn
On 6 Apr 2017, at 02:35, Ryan Schmidt wrote:
> export EDITOR=editor.sh
And does it work with MP_EDITOR? I just tried setting it in a vanilla vm, no
dice. I set -dv when editing a portfile, but no related information is being
logged.
On 6 Apr 2017, at 23:10, Joshua Root wrote:
> Yes it works with MP_EDITOR, I just checked. You never showed the exact
> command you are running; are you using sudo? That will strip all environment
> variables that are not listed in env_keep. VISUAL and EDITOR are there in the
> default sudoers,
On 10.8.5. I don't know if #52922 is related. Should I open a ticket?
Here's the log shortened to its last lines
:info:build /opt/local/bin/clang++-mp-4.0 -c -pipe -arch x86_64
-stdlib=macports-libstdc++ -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SD
On 8 Apr 2017, at 03:18, Ryan Schmidt wrote:
> That does look like the error described in #52922, but it is marked as fixed.
> What version of Xcode do you have on Mountain Lion? If it's not 5.1.1,
> upgrade to that, and the corresponding version of the command line tools.
Xcode 5.1.1, up-to-dat
On 8 Apr 2017, at 03:27, Ryan Schmidt wrote:
> On Apr 1, 2017, at 09:35, db wrote:
>> Could someone from MP team shed some light on this, please?
> All of MacPorts is on a best-effort basis. There is no guarantee of anything.
> Most of us are volunteers working on MacPorts in ou
On 9 Apr 2017, at 11:38, Ryan Schmidt wrote:
> I'd file a new ticket to start with, and mention #52922.
Fine, #53949.
On 9 Apr 2017, at 11:39, Ryan Schmidt wrote:
> Whether or not you use non-default variants, you can either automate the
> reinstallation of ports using the script mentioned in 3.e, or you can do it
> manually.
Ok, that tcl script states in the comments
# Once "good enough", integrate into port
On 8 Apr 2017, at 02:28, Stephen Baber wrote:
> JPortsUI has been updated due to an error when loading the port index.
I get an error when launching it from systems almost identical: OS X 10.8.5,
Java 1.6.0_65, port 2.4.1.
One uses rsync for the tree, another uses github and shows this error me
I checked #43923. Is there any workaround?
On 10 Apr 2017, at 04:55, Ryan Schmidt wrote:
> Right. It's here: https://github.com/macports/pallet/tree/gsoc15-pallet
It seems it'll not build on ≤10.8. Oh well…
69405b0d9bfa4671a6157827c9ec9d174bace4ef
MacPorts.framework: Don't build against 10.8 SDK
This should fix building MacPorts.framewor
On 10 Apr 2017, at 14:32, Ryan Schmidt wrote:
> I haven't tried to build Pallet from the latest git source lately. Have you?
Yes, I tried on OS X 10.8.5, Xcode 5.1.1. I cloned the repo and only changed
target and SDK to 10.8 and manually moved the framework to
~/Library/Frameworks/.
Here's a s
On 11 Apr 2017, at 04:13, Ryan Schmidt wrote:
> Ok. I don't see anything in the crash report that says to me that 10.8 is
> unsupported. I just see a crash, which someone needs to investigate and fix.
Should I add it to an existing ticket or open a new one or do nothing?
Unfortunately, it has n
d. This version, 2017-04-10, can be downloaded from
> https://sourceforge.net/projects/jportsui/files/
>
> Feel free to submit a ticket or feature request with SourceForge's
> "Tickets" navigation button or directly gmail me. Special thanks for
> help from Manfred Antar and db-iamsudo!
On 11 Apr 2017, at 09:18, Ryan Schmidt wrote:
> Sure, please file a new ticket; all the existing tickets seem to be about
> Pallet pre-GSoC2015.
Fine, #53960.
After installing a port with notes, these show after every command during the
same shell mode session on port 2.4.1. Is there any way to disable this great
feature?
Without arguments shows this warning
$ port-depgraph
Warning: It looks like your PortIndex file for file:///opt/local/myports may be
corrupt.
Warning: It looks like your PortIndex file for
file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ may
be corrupt.
Error: : syntax
On 12 Apr 2017, at 01:19, Ryan Schmidt wrote:
> That sounds like a bug. We probably didn't test the change with shell mode.
#53967, I hope I filed it correctly.
On 12 Apr 2017, at 11:02, db wrote:
> On 12 Apr 2017, at 01:19, Ryan Schmidt wrote:
>> That sounds like a bug. We probably didn't test the change with shell mode.
> #53967, I hope I filed it correctly.
That was quickly fixed. Should it be fine if I replace the binary, right?
On 11 Apr 2017, at 22:36, db wrote:
> Without arguments shows this warning
>
> $ port-depgraph
> Warning: It looks like your PortIndex file for file:///opt/local/myports may
> be corrupt.
> Warning: It looks like your PortIndex file for
> file:///opt/local/var/macpor
On 12 Apr 2017, at 16:21, Ryan Schmidt wrote:
> If you want to get this fix right now, before the next version of MacPorts is
> released, the official way would be to check out the master of the repository
> and build the whole thing from source.
Oh well…from what I gathered in history, last fi
On 13 Apr 2017, at 17:38, Rainer Müller wrote:
> You are effectively running it with an empty argument, which is not a valid
> port name:
> $ port-depgraph ""
> That could indeed be handled more graceful. The source can be found here
> after the move to GitHub:
> https://github.com/macports/mac
On 14 Apr 2017, at 01:59, Ryan Schmidt wrote:
> Sure. That's still valid. There haven't been any changes in port-depgraph
> since we moved to GitHub so there's no particular advantage to switching the
> portfile to GitHub yet.
I think the tcl script should be in base, the python script might be
I filed #53994, #53995, #53996 for highlight, nmap and ostinato respectively,
failing to build with libc++. I'd appreciate if anyone could peek at the logs
and recognize a pattern or tell these are unrelated.
I wanted to install texinfo which is actually a leaf of coreutils, but `sudo
port install texinfo` doesn't make it a requested port, as I would expect. Is
it intended behaviour? I suppose, I could either uninstall leaves and reinstall
it, or use setrequested.
On 18 Apr 2017, at 13:07, Ryan Schmidt wrote:
> Yes, installing a port should mark it requested. I'm unclear what happened in
> your situation.
This is what I do:
Last login: Tue Apr 18 14:14:12 on ttys001
tests-mac:~ test$
tests-mac:~ test$ port version
Version: 2.4.1
tests-mac:~ test$
tests
On 18 Apr 2017, at 14:43, Ryan Schmidt wrote:
> Ok fine. So texinfo got installed as a dependency of coreutils. You didn't
> ask for it directly, so it was not marked requested.
> Then, after that, you asked MacPorts to directly install texinfo. Since it
> was already installed, MacPorts did not
On 18 Apr 2017, at 09:50, db wrote:
> I filed #53994, #53995, #53996 for highlight, nmap and ostinato respectively,
> failing to build with libc++. I'd appreciate if anyone could peek at the logs
> and recognize a pattern or tell these are unrelated.
highlight (#53994) and nmap
Thanks Ken for the detailed post.
On 18 Apr 2017, at 17:45, Ken Cunningham
wrote:
> There are two issues:
> 1. cxx11 features required.
> ...
> Although you could say the Portfiles should all be updated as this is
> recognized, it is in the end MUCH easier to install a modern compiler on your
On 19 Apr 2017, at 10:13, Mojca Miklavec wrote:
> https://trac.macports.org/wiki/XcodeVersionInfo
That doesn't tell me anything different from the output I posted. I still don't
exactly know which clang version I have.
> You would run into problems if you installed/built existing ports against
On 19 Apr 2017, at 10:59, Chris Jones wrote:
> You cannot really compare the stock LLVM/Clang releases to the Apple versions.
I read https://trac.macports.org/wiki/UsingTheRightCompiler and this comment
from Rainer, I guess, https://superuser.com/a/130474 and thus I'm not quite
sure if this cha
On 19 Apr 2017, at 18:22, Ken Cunningham
wrote:
> You're right, that option is not listed there. It is listed in the
> LibCxxOnOlderSystems instructions, which is where I originally found it.
> It looks like this, in macports.conf on my system.
> default_compilers macports-clang-3.8
Are t
On 20 Apr 2017, at 00:13, Ken Cunningham
wrote:
> I think the Lion and Mountain Lion LibCxxOnOlderSystems instructions could
> probably suggest/recommend installing and setting the default compiler to
> something newer, but I defer to the gurus here.
After skimming the instructions for 10.6, t
On 20 Apr 2017, at 19:01, Ken Cunningham
wrote:
> Now to be fair, IF you get a build problem, there are increased expectations
> on you to check into it before you file a ticket about it. Specifically, try
> to build it with a stock clang compiler and see if that builds your port. If
> that do
On 20 Apr 2017, at 20:06, Ken Cunningham
wrote:
> On 2017-04-20, at 10:42 AM, db wrote:
>> Could you please tell me if you see the warning I mentionend and the
>> following line in every `port info` result?
>> Build Dependencies: clang-3.x
> Yes i do see that too - b
On 20 Apr 2017, at 22:54, Ken Cunningham
wrote:
> You’ve made clang-3.9 a build dep for everything by setting the default
> compiler to clang-3.9. It will always be listed, for all ports.
I often check dependencies and sizes with a couple of functions and these are
now a mess. I suppose I coul
On 20 Apr 2017, at 19:21, René J.V. Bertin wrote:
> I ran into what looks to be a bug in Apple's fullscreen algorithms. On 10.9.5
> with screens DO NOT have separate spaces:
> ...
> Same happens with a Qt-based console emulator so this is not a bug in
> Terminal.app .
I couldn't reproduce it on
I thought of upgrading strings and found it in binutils. During installation a
warning showed which doesn't seem to hold true at least from inspecting the
contents tracked by port command, and the notes advise to uninstall it. It has
no maintainer. Any ideas?
[test/Desktop] > install binutils
-
On 22 Apr 2017, at 16:16, Rainer Müller wrote:
> As identified by going back in history with 'git blame':
> https://trac.macports.org/changeset/67114
Is that still the case? binutils' binaries are prepended with g like those from
coreutils — and there's no gnubin dir.
On a 10.8.5-system with default compiler qt5 @5.7.1 and qt56 @5.6.2 require
clang-4.0 to build, while another whose compiler is set to clang-3.9 shows this
as dependency. Can anyone confirm the former?
On 22 Apr 2017, at 21:27, Ken Cunningham
wrote:
> For your other situation where the cxx_stdlib has been set to libc++, this
> whitelisting will not be forced
Why not? I'm missing something.
On 22 Apr 2017, at 21:58, Ryan Schmidt wrote:
> Sounds plausible. What's your question / problem with this?
Ken already point me to cxx11-1.1.tcl, but I still don't get why 4.0 isn't
whitelisted in a system whose default is set to 3.9.
On 22 Apr 2017, at 20:21, Ryan Schmidt wrote:
> Feel free to re-test the ports that failed to build back then that caused us
> to add that warning.
#22539 atlas (also #22674) -> it built for hours and I didn't let it finish,
sorry
#22679 wine-crossover-games -> couldn't find a port by that nam
On 24 Apr 2017, at 21:24, Ryan Schmidt wrote:
>> On Apr 24, 2017, at 14:22, db wrote:
>> #22539 atlas (also #22674) -> it built for hours and I didn't let it
>> finish, sorry
> Yes atlas takes hours to build.
This one I won't try any further.
>> #22679
On 22 Apr 2017, at 23:05, Ken Cunningham
wrote:
> because cxx_stdlib will equal libc++ and therefore this test (which would
> lead to the code that does the whitelisting) will fail.
Bear with me — what I actually had in mind was, since we have
LibcxxOnOlderSystems instructions, why doesn't it
1 - 100 of 239 matches
Mail list logo
