Looking to resolve Qemu on AppleSilicon build failure

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

Looking to resolve Qemu on AppleSilicon build failure

Blake Garner-2
I have been unsuccessfully trying to figure out how to resolve this issue with qemu builds on AppleSilicon hardware. 


My suspicion is that the build is not using the correct architecture when setting up the include directories for part of the build. This is based on some of the build log output. As noted in the ticket I was able to build qemu on the same system outside of MacPorts so again that points me to some of the configurations in the port. 

Any suggestions on what to look for here? Seems like I should be able to compare the output of the configure scripts to isolate differences between the working and not working builds? 

Thanks,
Blake



Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Joshua Root-8
On 2021-2-18 08:33 , Blake Garner wrote:

> I have been unsuccessfully trying to figure out how to resolve this
> issue with qemu builds on AppleSilicon hardware.
>
> https://trac.macports.org/ticket/62116 
> <https://trac.macports.org/ticket/62116>
>
> My suspicion is that the build is not using the correct architecture
> when setting up the include directories for part of the build. This is
> based on some of the build log output. As noted in the ticket I was able
> to build qemu on the same system outside of MacPorts so again that
> points me to some of the configurations in the port.
>
> Any suggestions on what to look for here? Seems like I should be able to
> compare the output of the configure scripts to isolate differences
> between the working and not working builds?

Are you building with the same configure args as the port? The --cpu=
option is the first obvious thing I see that might be relevant. Maybe
qemu needs to update its config.guess and config.sub, or maybe it just
wants you to say "aarch64" instead of "arm64".

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Rainer Müller-4
On 18/02/2021 05.23, Joshua Root wrote:

> On 2021-2-18 08:33 , Blake Garner wrote:
>> I have been unsuccessfully trying to figure out how to resolve this issue with
>> qemu builds on AppleSilicon hardware.
>>
>> https://trac.macports.org/ticket/62116 <https://trac.macports.org/ticket/62116>
>>
>> My suspicion is that the build is not using the correct architecture when
>> setting up the include directories for part of the build. This is based on
>> some of the build log output. As noted in the ticket I was able to build qemu
>> on the same system outside of MacPorts so again that points me to some of the
>> configurations in the port.
>>
>> Any suggestions on what to look for here? Seems like I should be able to
>> compare the output of the configure scripts to isolate differences between the
>> working and not working builds?
>
> Are you building with the same configure args as the port? The --cpu= option is
> the first obvious thing I see that might be relevant. Maybe qemu needs to update
> its config.guess and config.sub, or maybe it just wants you to say "aarch64"
> instead of "arm64".

That's it exactly, QEMU's build system expects this to be --cpu=aarch64.

There is already an open work-in-progress pull request that addresses this,
among other related issues for the Apple M1. It wasn't linked at the Trac ticket
yet, but I added that just now.

https://github.com/macports/macports-ports/pull/9955

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Blake Garner-2
Thanks for closing the loop on that. I'll do some testing with that PR as it includes the needed patches to support hypervisor.framework. 

Blake

On Thu, Feb 18, 2021 at 9:36 AM Rainer Müller <[hidden email]> wrote:
On 18/02/2021 05.23, Joshua Root wrote:
> On 2021-2-18 08:33 , Blake Garner wrote:
>> I have been unsuccessfully trying to figure out how to resolve this issue with
>> qemu builds on AppleSilicon hardware.
>>
>> https://trac.macports.org/ticket/62116 <https://trac.macports.org/ticket/62116>
>>
>> My suspicion is that the build is not using the correct architecture when
>> setting up the include directories for part of the build. This is based on
>> some of the build log output. As noted in the ticket I was able to build qemu
>> on the same system outside of MacPorts so again that points me to some of the
>> configurations in the port.
>>
>> Any suggestions on what to look for here? Seems like I should be able to
>> compare the output of the configure scripts to isolate differences between the
>> working and not working builds?
>
> Are you building with the same configure args as the port? The --cpu= option is
> the first obvious thing I see that might be relevant. Maybe qemu needs to update
> its config.guess and config.sub, or maybe it just wants you to say "aarch64"
> instead of "arm64".

That's it exactly, QEMU's build system expects this to be --cpu=aarch64.

There is already an open work-in-progress pull request that addresses this,
among other related issues for the Apple M1. It wasn't linked at the Trac ticket
yet, but I added that just now.

https://github.com/macports/macports-ports/pull/9955

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Blake Garner-2
I was able to build qemu on my m1 mini with the port from the linked PR! Should be able to test it and confirm hvf is working as expected this week. Also I ran into an issue similar to https://trac.macports.org/ticket/60189 when trying to use the Xcode 12.5 Beta 2 command line tools to build the qemu port. Reverting to the Xcode cli tools 12.4 worked. 

Blake

On Thu, Feb 18, 2021 at 10:14 AM Blake Garner <[hidden email]> wrote:
Thanks for closing the loop on that. I'll do some testing with that PR as it includes the needed patches to support hypervisor.framework. 

Blake

On Thu, Feb 18, 2021 at 9:36 AM Rainer Müller <[hidden email]> wrote:
On 18/02/2021 05.23, Joshua Root wrote:
> On 2021-2-18 08:33 , Blake Garner wrote:
>> I have been unsuccessfully trying to figure out how to resolve this issue with
>> qemu builds on AppleSilicon hardware.
>>
>> https://trac.macports.org/ticket/62116 <https://trac.macports.org/ticket/62116>
>>
>> My suspicion is that the build is not using the correct architecture when
>> setting up the include directories for part of the build. This is based on
>> some of the build log output. As noted in the ticket I was able to build qemu
>> on the same system outside of MacPorts so again that points me to some of the
>> configurations in the port.
>>
>> Any suggestions on what to look for here? Seems like I should be able to
>> compare the output of the configure scripts to isolate differences between the
>> working and not working builds?
>
> Are you building with the same configure args as the port? The --cpu= option is
> the first obvious thing I see that might be relevant. Maybe qemu needs to update
> its config.guess and config.sub, or maybe it just wants you to say "aarch64"
> instead of "arm64".

That's it exactly, QEMU's build system expects this to be --cpu=aarch64.

There is already an open work-in-progress pull request that addresses this,
among other related issues for the Apple M1. It wasn't linked at the Trac ticket
yet, but I added that just now.

https://github.com/macports/macports-ports/pull/9955

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Blake Garner-2
Building with the vnc variant is failing for me at the configure step. I was able to resolve a previous ld error by reinstalling xcode cli tools. Doesn't look like that is the issue with the attached errors. 

ProductName:    macOS
ProductVersion: 11.3
BuildVersion:   20E5196f

Xcode 12.4
Build version 12D4e

sudo port install qemu +cocoa +target_arm +usb +vnc


https://gist.github.com/trodemaster/249f812e6b66275e5649b219dd8f92cc


On Thu, Feb 18, 2021 at 12:03 PM Blake Garner <[hidden email]> wrote:
I was able to build qemu on my m1 mini with the port from the linked PR! Should be able to test it and confirm hvf is working as expected this week. Also I ran into an issue similar to https://trac.macports.org/ticket/60189 when trying to use the Xcode 12.5 Beta 2 command line tools to build the qemu port. Reverting to the Xcode cli tools 12.4 worked. 

Blake

On Thu, Feb 18, 2021 at 10:14 AM Blake Garner <[hidden email]> wrote:
Thanks for closing the loop on that. I'll do some testing with that PR as it includes the needed patches to support hypervisor.framework. 

Blake

On Thu, Feb 18, 2021 at 9:36 AM Rainer Müller <[hidden email]> wrote:
On 18/02/2021 05.23, Joshua Root wrote:
> On 2021-2-18 08:33 , Blake Garner wrote:
>> I have been unsuccessfully trying to figure out how to resolve this issue with
>> qemu builds on AppleSilicon hardware.
>>
>> https://trac.macports.org/ticket/62116 <https://trac.macports.org/ticket/62116>
>>
>> My suspicion is that the build is not using the correct architecture when
>> setting up the include directories for part of the build. This is based on
>> some of the build log output. As noted in the ticket I was able to build qemu
>> on the same system outside of MacPorts so again that points me to some of the
>> configurations in the port.
>>
>> Any suggestions on what to look for here? Seems like I should be able to
>> compare the output of the configure scripts to isolate differences between the
>> working and not working builds?
>
> Are you building with the same configure args as the port? The --cpu= option is
> the first obvious thing I see that might be relevant. Maybe qemu needs to update
> its config.guess and config.sub, or maybe it just wants you to say "aarch64"
> instead of "arm64".

That's it exactly, QEMU's build system expects this to be --cpu=aarch64.

There is already an open work-in-progress pull request that addresses this,
among other related issues for the Apple M1. It wasn't linked at the Trac ticket
yet, but I added that just now.

https://github.com/macports/macports-ports/pull/9955

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

ryandesign2
Administrator


On Mar 4, 2021, at 00:16, Blake Garner wrote:

> Building with the vnc variant is failing for me at the configure step. I was able to resolve a previous ld error by reinstalling xcode cli tools. Doesn't look like that is the issue with the attached errors.
>
> ProductName:    macOS
> ProductVersion: 11.3
> BuildVersion:   20E5196f
>
> Xcode 12.4
> Build version 12D4e
>
> sudo port install qemu +cocoa +target_arm +usb +vnc
>
> https://gist.github.com/trodemaster/249f812e6b66275e5649b219dd8f92cc

It's better to file bug reports in the issue tracker...

Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

Blake Garner-2
I'll get another bug open for this. Hopefully, I can isolate the vnc variant build issue from the existing PR to fix the other arm64 build issue. The original bug I opened didn't get much response until it was discussed on the dl. 

With the existing PR is there a way to confirm if it's a successful building with +vnc on the build bots? 


On Thu, Mar 4, 2021 at 1:30 AM Ryan Schmidt <[hidden email]> wrote:


On Mar 4, 2021, at 00:16, Blake Garner wrote:

> Building with the vnc variant is failing for me at the configure step. I was able to resolve a previous ld error by reinstalling xcode cli tools. Doesn't look like that is the issue with the attached errors.
>
> ProductName:    macOS
> ProductVersion: 11.3
> BuildVersion:   20E5196f
>
> Xcode 12.4
> Build version 12D4e
>
> sudo port install qemu +cocoa +target_arm +usb +vnc
>
> https://gist.github.com/trodemaster/249f812e6b66275e5649b219dd8f92cc

It's better to file bug reports in the issue tracker...

Reply | Threaded
Open this post in threaded view
|

Re: Looking to resolve Qemu on AppleSilicon build failure

ryandesign2
Administrator
On Mar 4, 2021, at 11:39, Blake Garner wrote:
>
> I'll get another bug open for this. Hopefully, I can isolate the vnc variant build issue from the existing PR to fix the other arm64 build issue. The original bug I opened didn't get much response until it was discussed on the dl.

By all means if a bug report doesn't get attention, bring it up on the list. But a bug report should be the first step when reporting a problem.


> With the existing PR is there a way to confirm if it's a successful building with +vnc on the build bots?

Pull request CI systems and the buildbot used after the PR is merged only build default variants. Test your changes on your own system before you submit a PR.