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 2017-04-22 14:28, db wrote:
> 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?
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 Apr 22, 2017, at 10:02, db wrote:
>
> 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 —
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 Apr 22, 2017, at 11:56 AM, db wrote:
>
> 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?
The clang-4.0 dependency on a stock unmo
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 Apr 22, 2017, at 13:56, db wrote:
>
> 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?
Sounds plausible. What's your question / problem
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 2017-04-22, at 1:55 PM, db wrote:
> 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.
>
because
On 2017-04-22, at 1:55 PM, db wrote:
> 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.
>
because
> On Apr 22, 2017, at 15:55, db wrote:
>
> 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.
I gues
It is confusing for people like me who use MacPorts at a more casual level than
active developers get a message that “qt5-qtenginio” port should be removed and
then to have to figure out how to remove it without breaking other ports we
have installed, even if they are inactive.
In fact, I still
On Apr 22, 2017, at 20:02, Fielding, Eric J (329A) wrote:
>
> In fact, I still have a remaining broken port message that I don’t know how
> to solve:
> ---> Scanning binaries for linking errors
> ---> Found 1 broken file, matching files to ports
> ---> Found 1 broken port:
> py27-pyqt5 @5.
14 matches
Mail list logo