macOS 11 and Apple Silicon

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

macOS 11 and Apple Silicon

Jeremy Huddleston Sequoia
I just pushed some changes to base/master and dports/master to better support macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.

Some common issues to be aware of:

1) libtool required an update for the version bump.  This means many projects might need an autoreconf to build correctly.
2) arm64 builds with implicit-function-declaration warnings promoted to error because vararg and non-vararg functions have differnet calling conventions, thus a prototype is required.

#2 is easiest to fix when you see it in actual build failures (add a missing header include or protype), but  it's less obvious and more problematic when it occurs during project configuration.  There are many configure scripts that now fail certain checks because of a missing include.  MacPorts base was one such example, and you can see how I had to fix that here: 

 
Please reach out if you have any questions or concerns.

Thanks,
Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: macOS 11 and Apple Silicon

vincent habchi-2

> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia <[hidden email]> wrote:
>
> I just pushed some changes to base/master and dports/master to better support macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.

[…]

>  Please reach out if you have any questions or concerns.

We’re undoubtedly heading into a turbulence zone. Because not all of us will have early access to the new hardware (I won’t personally, and happen to have ordered the latest MacBook Air with an i7 CPU a few days ago…), it means that those who will will probably have to bear the burden of testing a lot of ports and reporting errors, while the maintainers won’t have the ability to test the fixes.

Wouldn’t it be possible to somehow set up a new hardware machine with MacPorts installed and give all maintainers the possibility to log into it and test their ports?

V.

Reply | Threaded
Open this post in threaded view
|

Re: macOS 11 and Apple Silicon

Stephen J. Butler
I'd think the promotion of implicit-function-declaration is something you'd be able to work on and fix in the x86 architecture too, and that seems to be the major first step here.

On Tue, Jun 23, 2020 at 1:41 AM Vincent Habchi <[hidden email]> wrote:

> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia <[hidden email]> wrote:
>
> I just pushed some changes to base/master and dports/master to better support macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.

[…]

>  Please reach out if you have any questions or concerns.

We’re undoubtedly heading into a turbulence zone. Because not all of us will have early access to the new hardware (I won’t personally, and happen to have ordered the latest MacBook Air with an i7 CPU a few days ago…), it means that those who will will probably have to bear the burden of testing a lot of ports and reporting errors, while the maintainers won’t have the ability to test the fixes.

Wouldn’t it be possible to somehow set up a new hardware machine with MacPorts installed and give all maintainers the possibility to log into it and test their ports?

V.

Reply | Threaded
Open this post in threaded view
|

Re: macOS 11 and Apple Silicon

Karan Sheth via macports-dev
Yes.  Installing the Xcode.app beta with support for Apple Silicon Macs and adding +universal to your default variants will be a good first step.  Note that you will need to explicitly set the universal arches in macports.conf right now (unless you are running on a DTK) since the value is based on the version of macOS and not the value of the SDK.

On Jun 23, 2020, at 12:08 AM, Stephen J. Butler <[hidden email]> wrote:

I'd think the promotion of implicit-function-declaration is something you'd be able to work on and fix in the x86 architecture too, and that seems to be the major first step here.

On Tue, Jun 23, 2020 at 1:41 AM Vincent Habchi <[hidden email]> wrote:

> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia <[hidden email]> wrote:
>
> I just pushed some changes to base/master and dports/master to better support macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.

[…]

>  Please reach out if you have any questions or concerns.

We’re undoubtedly heading into a turbulence zone. Because not all of us will have early access to the new hardware (I won’t personally, and happen to have ordered the latest MacBook Air with an i7 CPU a few days ago…), it means that those who will will probably have to bear the burden of testing a lot of ports and reporting errors, while the maintainers won’t have the ability to test the fixes.

Wouldn’t it be possible to somehow set up a new hardware machine with MacPorts installed and give all maintainers the possibility to log into it and test their ports?

V.


Reply | Threaded
Open this post in threaded view
|

Re: macOS 11 and Apple Silicon

ryandesign2
Administrator
In reply to this post by vincent habchi-2
Everyone, please use the new list addresses at lists.macports.org, not the old macosforge addresses that were deprecated in 2016.

On Jun 23, 2020, at 01:40, Vincent Habchi wrote:

> Wouldn’t it be possible to somehow set up a new hardware machine with MacPorts installed and give all maintainers the possibility to log into it and test their ports?

Unfortunately not. If you sign up to get beta versions of macOS or Xcode or if you apply to receive a developer transition kit machine, you are agreeing to an NDA that prohibits you from discussing it or sharing it with anyone.
Reply | Threaded
Open this post in threaded view
|

Re: macOS 11 and Apple Silicon

Clemens Lang-2
In reply to this post by Jeremy Huddleston Sequoia
Hi,

On Mon, Jun 22, 2020 at 01:19:34PM -0700, Jeremy Huddleston Sequoia wrote:
> 1) libtool required an update for the version bump.  This means many
> projects might need an autoreconf to build correctly.

Should we just make running autoreconf for autotools and automake builds
the default? This is already common in other packaging systems, and
while it does require additional build dependencies, it may also fix
other issues with outdated configure scripts.

--
Clemens