search

mozilla-mobile / focus-ios

⚠️ Firefox Focus (iOS) has moved to a new repository. It is now developed and maintained as part of: https://github.com/mozilla-mobile/firefox-ios
Mozilla Public License 2.0
1.26k stars 263 forks source link

Build error: building for iOS Simulator, but linking in object file built for iOS, for architecture arm64 #2600

Open st3fan opened 3 years ago

st3fan commented 3 years ago

We got the following report:

ld: in .../DerivedData/Blockzilla-hauvbqqyspuygldguczstwphcbba/Build/Products/FocusDebug-iphonesimulator
/MozillaRustComponents.framework/MozillaRustComponents(unix.o), building for iOS Simulator, but linking in
object file built for iOS, for architecture arm64

@isabelrios is this the same error you got?

@badboy @skhamis have you seen this error?

┆Issue is synchronized with this Jira Task

st3fan commented 3 years ago

THings tried to get past this:

Possibly started to happen after the the rust-components-swift change to 0.0.4.

skhamis commented 3 years ago

rust-components-swift is now 0.0.6 -- possibly try bumping to see if that resolves it?

st3fan commented 3 years ago

@isabelrios posted a build log and one thing that stood out there was that she got:

    export PLATFORM_NAME\=iphonesimulator
    export PLATFORM_PREFERRED_ARCH\=x86_64
    ....
    export VALID_ARCHS\=arm64\ x86_64

While for my build it says:

    export PLATFORM_NAME\=iphonesimulator
    export PLATFORM_PREFERRED_ARCH\=arm64
    ....
    export VALID_ARCHS\=arm64

It looks like the products are built correctly for ARM64 but then Xcode is trying to run on a x86 simulator?

st3fan commented 3 years ago

Let's see if this makes a difference https://github.com/mozilla-mobile/focus-ios/pull/2603

menghif commented 3 years ago

I am still getting the error with rust-components-swift 0.0.6

st3fan commented 3 years ago

Me too! I setup a new account on my M1 Mini and my build is failing now with this exact same issue. At least I have something concrete to explore now.

skhamis commented 3 years ago

@menghif or @st3fan, will it be possible to see the full Xcode dump just so I understand what Target and what command is being run before this error?

skhamis commented 3 years ago

Update: Turns out it does work if you have open with Rosetta checked for Xcode application so indeed it is an issue for non-rosetta M1s

Edit: If there is no issue with keeping Rosetta on, keeping rosetta turned on for Xcode might be the way to be unblocked until I can better understand what is going on (however, we are still going in the right direction as before, M1s wouldn't be able to run a-s even with rosetta!)

isabelrios commented 3 years ago

@st3fan yes, that's the same error I has having. And I did what @skhamis mentions above, open Xcode with Rosetta.

st3fan commented 3 years ago

Hey all, I've given this some more thought ...

After working in Xcode under Rosetta emulation I think I want to take a different path. Rosetta works, but builds are 3x slower and I get a lot of delays and choppiness and even beachballing in Xcode. It is definitely a noticeable step backward to develop under emulation. Since it is an absolute joy to work on M1 machines on this product, I don't want to compromise on developer ergonomics for this specific issue.

But at the same time I also do not want to stop working on getting Nimbus ready in Focus. Specially since it is very close to be done. But, the required UI to enable/disable experiments, and maybe even a first experiment, won't ship until Focus 40.

So what I want to do is disable Nimbus, or really the new App Services package, on main and revert back to the original Glean package that we used before that. Then at the same time we can wrap up the Nimbus work and test the integration on the nimbus branch, which we can ship in Focus 40. That release ships early December, which a code freeze date a month from now.

That gives us time to work on this issue while at the same time keeping things simple for our engineers and contributors. I am also ready to contribute to getting past this final packaging issue of course.

st3fan commented 3 years ago

One thing that I do not understand about this issue is why does it works for me.

I think it definitely has something to do with the fact that artifacts are cached in ~/Library/Caches/org.swift.swiftpm - but according to Xcode I am also up to date with the 0.0.6 package.

So what does that mean? Am I actually using a different version or is the problem maybe in a (cached) dependency of the AppServices SPM? Am I linking against an older version of a dependency that does not have this unix.o issue while the most recent build does?

My package cache looks like this:

-rw-r--r--  1 stefan  staff  0 13 Jul 10:51 CwlCatchException-dc25c313.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:51 CwlPreconditionTesting-d4f7dd0b.lock
-rw-r--r--  1 stefan  staff  0 19 May 13:55 Fuzi-eb1443ec.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:51 Nimble-b9e21ed2.lock
-rw-r--r--  1 stefan  staff  0 19 May 10:40 OHHTTPStubs-3a6c21d6.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:51 Quick-b5e44b9d.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:50 Reachability.swift-c06de472.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:52 RxDataSources-c46ad9a2.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:51 RxOptional-610576a3.lock
-rw-r--r--  1 stefan  staff  0 13 Jul 10:43 RxSwift-17ad69a9.lock
-rw-r--r--  1 stefan  staff  0 19 May 13:55 SnapKit-4cdad746.lock
-rw-r--r--  1 stefan  staff  0  4 Jun 11:44 SwURL-5f92b944.lock
-rw-r--r--  1 stefan  staff  0 27 Jul 07:15 SwiftKeychainWrapper-d7068500.lock
-rw-r--r--  1 stefan  staff  0 28 May 15:52 glean-swift-1ac010ff.lock
-rw-r--r--  1 stefan  staff  0 27 Jul 07:15 glean-swift-94dc6b18.lock
-rw-r--r--  1 stefan  staff  0 19 May 13:55 glean-swift-c2dca6d1.lock
-rw-r--r--  1 stefan  staff  0 19 May 14:28 glean-swift-fba00477.lock
-rw-r--r--  1 stefan  staff  0  1 Sep 17:04 rust-components-swift-68bea98c.lock
-rw-r--r--  1 stefan  staff  0 27 Jul 07:15 rust-components-swift-b8653822.lock
-rw-r--r--  1 stefan  staff  0 19 May 13:55 sentry-cocoa-a72b37d1.lock
-rw-r--r--  1 stefan  staff  0 30 Jul 11:54 swift-argument-parser-59ba1edd.lock
-rw-r--r--  1 stefan  staff  0 27 Jul 16:09 swift-argument-parser-71d4b286.lock
-rw-r--r--  1 stefan  staff  0 14 Oct 16:48 swift-protobuf-b2969a7a.lock
-rw-r--r--  1 stefan  staff  0 19 May 13:55 telemetry-ios-7c9f8d8e.lock

(I probably have a few more dependencies here unrelated to focus-ios)

And for the non-working setup it looks like this:


-rw-r--r--  1 john  staff  0 14 Oct 21:29 Fuzi-eb1443ec.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 SnapKit-4cdad746.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 SwiftKeychainWrapper-d7068500.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 glean-swift-94dc6b18.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 rust-components-swift-68bea98c.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 swift-protobuf-b2969a7a.lock
-rw-r--r--  1 john  staff  0 14 Oct 21:29 telemetry-ios-7c9f8d8e.lock```
skhamis commented 3 years ago

Update, I identified the issue (not known why just yet). It turns out it was building the rust components in debug instead of release -- a benefit is also we get faster swift package soon! I will update this issue when I cut a new release of rust-components-swift and validate it's working on non-rosetta M1

Will be fixed in this PR: https://github.com/mozilla/application-services/pull/4576