Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 28, 2018, at 21:10, Zero King wrote:

> Hi,
> 
> On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:
>> Source code and pkgs for MacPorts 2.5.0-beta1 are now
>> available [1]. Testing of either of these install methods is helpful.
> 
> Now that 2.5.0 is released, we should protect the release-2.5 branch in
> macports-base to disable force pushing and prevent it from being deleted
> accidentally.

Done.

We should have done that the moment the branch was created.

We should update our documentation (macports-base/portmgr/ReleaseProcess.md) to 
include that step.

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

Hi,

On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:

Source code and pkgs for MacPorts 2.5.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.


Now that 2.5.0 is released, we should protect the release-2.5 branch in
macports-base to disable force pushing and prevent it from being deleted
accidentally.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 14:38, Ken Cunningham wrote:

> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote:
> 
>> The error occurs when there is a mismatch between which C++ standard library 
>> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set 
>> to its default value) and which C++ standard library it actually links with.
> 
> Right. 
> 
> Indeed I did not realize that each and every portfile would be examined for 
> cxx_stdlib overrides for each different system configuration, and that would 
> be integrated into the check mechanism for the build.
> 
> So if he had wanted to (and assuming the linkages worked out), Zero could 
> have also just as correctly put 
> 
> configure.cxx_stdlib libstdc++
> 
> into his unar portfile, and left things alone.

Yes, if unar does not link with any C++ libraries, and does not provide any C++ 
libraries, that would also be fine.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ken Cunningham]

> On May 26, 2018, at 12:27 PM, Ryan Schmidt  wrote:
> 

> The error occurs when there is a mismatch between which C++ standard library 
> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set to 
> its default value) and which C++ standard library it actually links with.
> 

Right. 

Indeed I did not realize that each and every portfile would be examined for 
cxx_stdlib overrides for each different system configuration, and that would be 
integrated into the check mechanism for the build.

So if he had wanted to (and assuming the linkages worked out), Zero could have 
also just as correctly put 

configure.cxx_stdlib libstdc++

into his unar portfile, and left things alone.

Ken

Re: MacPorts 2.5.0-beta1 now available for testing

[Ken Cunningham]

> On May 26, 2018, at 9:40 AM, Ryan Schmidt  wrote:
> 

> Unfortunately, we have no way to tell Xcode to use one of our compilers. I 
> believe we need to create some kind of Xcode-specific file to tell it about 
> each of our compilers, then update the xcode portgroup to use that. Nobody's 
> done that so far.
> 

I’ve been using a simple workaround for several years now, but kept it to 
myself so far.

Simple enough to symlink  the compiler / cctools parts / and ld in the 10.6 SDK 
to the equivalents in /opt/local.

With this, I can force clang-3.9 / libc++ xcode builds on 10.6.8 with a few 
simple xcode.build.settings, and build lots of things that way.

So it’s quite possible, but I don’t know if it’s bakeable into a macports port.

Ken

Re: MacPorts 2.5.0-beta1 now available for testing

[Ken Cunningham]

> On May 26, 2018, at 9:49 AM, Ryan Schmidt  wrote:
> 
> 
> On May 26, 2018, at 11:48, Ken Cunningham wrote:
> 
>> Well I think you did the cmake finaggeling last time Not sure you could 
>> find a better way, but I wait to see...
> 
> I don't recall what you're referring to.

if {!((${os.platform} eq "darwin" && ${os.major} < 10) || ${build_arch} eq 
"ppc" || ${build_arch} eq "ppc64")} {
depends_lib-append port:libcxx
configure.cxx_stdlib libc++
}


So this forces a build against libc++ on systems that have cxx_stdlib set to 
libstdc++.

Will this trigger an error? 

Maybe I don’t understand exactly how the error mechanism is setup.

K

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:48, Ken Cunningham wrote:

> Well I think you did the cmake finaggeling last time Not sure you could 
> find a better way, but I wait to see...

I don't recall what you're referring to.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ken Cunningham]

Well I think you did the cmake finaggeling last time Not sure you could 
find a better way, but I wait to see...

K 

Sent from my iPhone

> On May 26, 2018, at 9:40 AM, Ryan Schmidt  wrote:
> 
>> On May 26, 2018, at 11:15, Ken Cunningham wrote:
>> 
>>> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
>>> 
>>> It's "broken" in that it links with libstdc++, even though MacPorts 
>>> believes it will link with libc++ on your system. The rev-upgrade code in 
>>> previous versions of MacPorts did not check for this kind of "broken".
>>> 
>>> Fix it by fixing the build system to use the right C++ standard library 
>>> (the one in the ${configure.cxx_stdlib} variable).
>> 
>> So this particular port comes up with this error probably because the 
>> deployment target is set to 10.6 in the xcode project. 
>> 
>> But there are _lots_ of ports that don’t build with the c++ stdlib specified 
>> in cxx_stdlib.
>> 
>> These are forced one way or the other in a way that works to fix a problem — 
>> eg. cmake and many others.
> 
> Then all of these ports need to be fixed. Either make the port use the C++ 
> standard library that MacPorts sets in configure.cxx_stdlib, or else set 
> configure.cxx_stdlib to the C++ standard library that the port will use (this 
> is acceptable if the port uses no libraries and provides no libraries; 
> mongodb is an example).
> 
> 
>> Also, on systems with libcxxonoldersystems, xcodebuild will not accept 
>> certain settings on certain systems, even if we know they could work with 
>> our newer compilers.
> 
> Unfortunately, we have no way to tell Xcode to use one of our compilers. I 
> believe we need to create some kind of Xcode-specific file to tell it about 
> each of our compilers, then update the xcode portgroup to use that. Nobody's 
> done that so far.
> 
> 
>> We might see quite a few errors with this, I suspect…
> 
> Then we will have to fix quite a few things.
> 

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:15, Ken Cunningham wrote:

> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
> 
>> It's "broken" in that it links with libstdc++, even though MacPorts believes 
>> it will link with libc++ on your system. The rev-upgrade code in previous 
>> versions of MacPorts did not check for this kind of "broken".
>> 
>> Fix it by fixing the build system to use the right C++ standard library (the 
>> one in the ${configure.cxx_stdlib} variable).
> 
> So this particular port comes up with this error probably because the 
> deployment target is set to 10.6 in the xcode project. 
> 
> But there are _lots_ of ports that don’t build with the c++ stdlib specified 
> in cxx_stdlib.
> 
> These are forced one way or the other in a way that works to fix a problem — 
> eg. cmake and many others.

Then all of these ports need to be fixed. Either make the port use the C++ 
standard library that MacPorts sets in configure.cxx_stdlib, or else set 
configure.cxx_stdlib to the C++ standard library that the port will use (this 
is acceptable if the port uses no libraries and provides no libraries; mongodb 
is an example).


> Also, on systems with libcxxonoldersystems, xcodebuild will not accept 
> certain settings on certain systems, even if we know they could work with our 
> newer compilers.

Unfortunately, we have no way to tell Xcode to use one of our compilers. I 
believe we need to create some kind of Xcode-specific file to tell it about 
each of our compilers, then update the xcode portgroup to use that. Nobody's 
done that so far.


> We might see quite a few errors with this, I suspect…

Then we will have to fix quite a few things.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ken Cunningham]

> On May 25, 2018, at 12:05 PM, Ryan Schmidt  wrote:
> 
> It's "broken" in that it links with libstdc++, even though MacPorts believes 
> it will link with libc++ on your system. The rev-upgrade code in previous 
> versions of MacPorts did not check for this kind of "broken".
> 
> Fix it by fixing the build system to use the right C++ standard library (the 
> one in the ${configure.cxx_stdlib} variable).
> 


So this particular port comes up with this error probably because the 
deployment target is set to 10.6 in the xcode project. 

But there are _lots_ of ports that don’t build with the c++ stdlib specified in 
cxx_stdlib.

These are forced one way or the other in a way that works to fix a problem — 
eg. cmake and many others.

Also, on systems with libcxxonoldersystems, xcodebuild will not accept certain 
settings on certain systems, even if we know they could work with our newer 
compilers.


We might see quite a few errors with this, I suspect…

Ken

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

On Fri, May 25, 2018 at 02:05:00PM -0500, Ryan Schmidt wrote:


On May 25, 2018, at 12:57, Zero King wrote:


On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:

It's been a week with no new tickets filed against base. I'll give it
one more week and then, if nothing comes up, tag a release candidate.

- Josh


I tried the rc1, and unar is now "broken". How can I fix it?

unar is using libstdc++ (this installation is configured to use libc++)
Error: Port unar is still broken after rebuilding it more than 3 times.


It's "broken" in that it links with libstdc++, even though MacPorts believes it will link 
with libc++ on your system. The rev-upgrade code in previous versions of MacPorts did not check for 
this kind of "broken".

Fix it by fixing the build system to use the right C++ standard library (the 
one in the ${configure.cxx_stdlib} variable).


Thanks, fixed in 
https://github.com/macports/macports-ports/commit/90b64720a4c3c4f400c4f2eaeee8b0071232ea30.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 25, 2018, at 12:57, Zero King wrote:

> On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:
>> It's been a week with no new tickets filed against base. I'll give it
>> one more week and then, if nothing comes up, tag a release candidate.
>> 
>> - Josh
> 
> I tried the rc1, and unar is now "broken". How can I fix it?
> 
> unar is using libstdc++ (this installation is configured to use libc++)
> Error: Port unar is still broken after rebuilding it more than 3 times.

It's "broken" in that it links with libstdc++, even though MacPorts believes it 
will link with libc++ on your system. The rev-upgrade code in previous versions 
of MacPorts did not check for this kind of "broken".

Fix it by fixing the build system to use the right C++ standard library (the 
one in the ${configure.cxx_stdlib} variable).

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

Hi,

On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:

It's been a week with no new tickets filed against base. I'll give it
one more week and then, if nothing comes up, tag a release candidate.

- Josh


I tried the rc1, and unar is now "broken". How can I fix it?

unar is using libstdc++ (this installation is configured to use libc++)
Error: Port unar is still broken after rebuilding it more than 3 times.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature