ARCHS problem building Firestorm

46 views
Skip to first unread message

Laurent Rathle

unread,
Aug 3, 2022, 11:47:58 AM8/3/22
to opensource-dev
Hello,
I'm trying to build Firestorm on a Mac Studio M1, and I get a problem with i386 deprecated message :

 None of the architectures in ARCHS (i386) are valid. Consider setting ARCHS to $(ARCHS_STANDARD) or updating it to include at least one value from VALID_ARCHS (arm64, arm64e, i386, x86_64). (in target 'media_plugin_libvlc' from project 'Firestorm')
error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture. (in target 'llplugin' from project 'Firestorm')

Where can I change the architecture setting, and which one should I use (arm64 or arm64e or x86_64)?

Thank you 

Dayturn

unread,
Aug 3, 2022, 12:04:15 PM8/3/22
to Laurent Rathle, opensource-dev
As far as I can see from the source repository, Firestorm is built with a deployment target of macOS 10.11 – which is also included in the Info.plist as

<key>LSMinimumSystemVersion</key>
<string>10.11</string>

macOS 10.11 still had full 32-bit support, so it might be that both i386 and x86_64 are selected as default by cmake when the build files are generated. But it might also be that xcode_build does this and adds arm64 when you try to do the build on a Studio.

Xcode on M1 cannot generate the 32-bit code at all, so that is one issue. It goes to say that viewer code does not build for ARM at all.



On my viewer build (which is now compiled with Xcode 13.4.1 on a M1 Mac mini, in the Variables.cmake file, the beginning of the

if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

Looks like this to ensure that x86_64 architecture is the only one Xcode tries to build when running on Apple Silicon.


if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
  set(DARWIN 1)
  
  # now we only support Xcode 13.3 or higher using 12.3 (Monterey), with minimum macOS requirement of 10.14 (Mojave)
  set(CMAKE_OSX_ARCHITECTURES "x86_64" )
  set(XCODE_VERSION 13.4.1)
  set(CMAKE_OSX_DEPLOYMENT_TARGET 10.14)

You have to set the CMAKE_OSX_ARCHITECTURES as your first statement, or cmake will generate build files for the native architecture of the build machine.


My code repository is in http://www.dayturn.com:5000/dayturn-core for the 3.0 development build. 

Hope that fix your issue.
Geir




--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/71663ede-1377-46b5-9fbe-0b3294a5bcb0n%40lists.secondlife.com.

Laurent Rathle

unread,
Aug 3, 2022, 2:21:02 PM8/3/22
to opensource-dev, Dayturn, opensource-dev
Hello,

Thank you. I've changed Variables.cmake according to your advice, and variables in fs-build-variables to have "-mmacosx-version-min=10.13" in it instead of "-mmacosx-version-min=10.11" in it. It's better, but build still fails this time with this error. 

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no library created (no object files in input files matching -arch_only x86_64)

Geir Nøklebye

unread,
Aug 3, 2022, 2:25:18 PM8/3/22
to Laurent Rathle, opensource-dev
Did you generate a completely new build folder like in deleting /reaming the old and let autobuild configure generate a completely new one for you?



Tonya Souther

unread,
Aug 3, 2022, 3:10:13 PM8/3/22
to opensource-dev
Firestorm does not, AFAIK, built on Apple Silicon yet. There are no versions of the libraries built for it.

The reason that it specified minimum system version as 10.11 is because if that is set higher, then the text becomes unacceptably fuzzy on Retina displays unless you run Firestorm in a window with UI scaling turned off. This was one that I went back and forth with the QA folks over; in particular, it precludes setting Firestorm to operate in dark mode.

It should be feasible to get Firestorm (and the other viewers, for that matter) to build on ARM, but it will take a substantial amount of work. I'm mildly surprised LL hasn't done it yet. I've moved away from using the Mac for SL due to Apple's stance on OpenGL, but it took several days to build everything to get it working in 64-bit mode when I did that.

Geir Nøklebye

unread,
Aug 3, 2022, 3:18:27 PM8/3/22
to Tonya Souther, opensource-dev
We are not talking about building an ARM version of Firestorm (or any other viewer for that sake), but to build the 64-bit Intel version on a machine with Apple Silicon like I do with my viewer builds.

The trick is to a) have all the libs stripped of i386 code, and then b) coerce cmake into generating build files for x86_64 only.

In addition there are quite a few other issues to be resolved to get you a successful build Intel build on Apple Silicone; it is primarily a matter of replacing some deprecated functions, and to clean up memory management in the Objective-C code. – Which is what I have done in my code. 

Finally you have to build with Xcode 13.2 or higher to successfully complete the build and to notarize. – Which force you to upgrade to Monterey while you are at it. 


To build a AS clean viewer is a completely different kettle of fish...



Laurent Rathle

unread,
Aug 3, 2022, 5:10:49 PM8/3/22
to opensource-dev, Geir Nøklebye, opensource-dev

No I didn't. It's done now. The strange thing is that configure hasn't created a "build-darwin-x86_64" folder, but has put all the folders under the phoenix-firestorm folder. Anyway, it has started to build and failed with a new error message. I've read your answer to tonya, and it seems I'm not at the end of errors messages :). This one is : 

Error copying file (if different) from "/Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/packages/lib/release/libGLOD.dylib" to "/Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/sharedlibs/RelWithDebInfo/Resources/libGLOD.dylib".
Command PhaseScriptExecution failed with a nonzero exit code


PhaseScriptExecution Generate\ sharedlibs/RelWithDebInfo/Resources/libGLOD.dylib /Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/llcommon/Firestorm.build/Release/stage_third_party_libs.build/Script-5FEEBF79D07F9A9BFD150B4E.sh (in target 'stage_third_party_libs' from project 'Firestorm')
(1 failure)

This error is normal, since "packages/lib/release/libGLOD.dylib" doesn't exist. The lib folder itself doesn't exist.

Dayturn

unread,
Aug 3, 2022, 5:14:27 PM8/3/22
to Laurent Rathle, opensource-dev
Are you building it with RelWithDebInfoOS? 
Try configure and build as ReleaseOS because then it should create the Release folder structure for you.



Laurent Rathle

unread,
Aug 3, 2022, 5:24:50 PM8/3/22
to opensource-dev, Dayturn, opensource-dev

I'll try that, thank you.

I've found libGLOD.dylib. I just had to build 3p-glod. The next one I have to find is libapr. I'll do that tomorrow.

Laurent Rathle

unread,
Aug 5, 2022, 7:55:55 AM8/5/22
to opensource-dev, Dayturn, opensource-dev

I've solved several issues with missing .dylib files, but now build fails with this error :

Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -D -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -L/Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/cmake/Release -filelist /Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/cmake/Firestorm.build/Release/cmake.build/Objects-normal/x86_64/cmake.LinkFileList -dependency_info /Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/cmake/Firestorm.build/Release/cmake.build/Objects-normal/x86_64/cmake_libtool_dependency_info.dat -o /Users/laurentr2d2/Documents/Firestorm/Compilation/phoenix-firestorm/cmake/Release/libcmake.a

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no library created (no object files in input files matching -arch_only x86_64)
Command Libtool failed with a nonzero exit code

From your message above, it seems much more complicated to build for M1. IF I have to dig in the code, I'm not sure to have enough knowledge for that.

Geir Nøklebye

unread,
Aug 5, 2022, 9:29:39 AM8/5/22
to Laurent Rathle, opensource-dev
I have chosen to still build with autobuild version1.0 because it makes it easer to have control over configuration compared to the variables settings file used in later versions. Besides when you only build 64-bit targets; anyway...

a) I assume you are on macOS 12.5 and with Xcode 13.4.1?

b) do you use homebrew or macports?  – I use macports because homebrew is in many ways a linux hack made to work on macOS, while macports is BSD, which is also the BSD Unix subsystem in macOS. I find there is better compatibility with macports.

c) I use cmake 3.23.0 right now, but I believe you must be on 3.19.x minimum for it to properly resolve the sysroot when building on Apple Silicon

d) In my Variables.cmake I have a line for Darwin with

set(CMAKE_OSX_SYSROOT macosx)  

You can try and set your -iwithsysroot to macosx on line 61 in your FS variables file, rather than the full patch to the SDK

e) Do you build from the command line? 
If so, does it make any difference if you open the project in Xcode and build it there?
If you do build in Xcode, make sure to edit the Product>Scheme>Edit Scheme.. and set Build Configuration to Release with Executable to None

If you open the generated project in Xcode, the Build Settings>Architectures shall be set to:

Additional SDKs not set (blank)
Architectures x86_64 (it also works with arm64 as long as cmake has generated build files for x86_64)
Base SDK macOS
Build Active Architectures Only No
Excluded Architectures not set (blank)
Supported Platforms macOS

In addition macOS Deployment Target must be set to macOS 10.13 or higher or you will get an error message that the deployment target is not supported by the SDK


Finally, yes, you will have to change the code in quite a few places to make it build on Xcode 13.2 or higher


Laurent Rathle

unread,
Aug 10, 2022, 12:46:07 PM8/10/22
to opensource-dev, Geir Nøklebye, opensource-dev
Thank you for all your help, but I don't have enough developer skills to dig in the code and find what I have to change. Also, I guess I will have to redo the work each time Firestorm get an update. Also thank you for the Dayturn viewer.

Geir Nøklebye

unread,
Aug 10, 2022, 1:09:43 PM8/10/22
to Laurent Rathle, opensource-dev
Yeah, you’d have to fork it to make it less painful, but that is probably not what you were after anyway.

Eventually all the viewers will have to go through the same updates as Xcode gets more and more picky for every release, or they won’t compile / run at all on new system versions. 

There will be a new Dayturn build posted a bit later today for both macOS and 64-bit Windows which has the new functionality from SL 6.6.2 for copying and pasting build parameters (+keeping some of the old). AFAIC test it works OK, but I have much more complicated builds to test it on in my Opensim grid, and I have not back ported it to the current Opensim viewer version as the 3.0 series builds will morph into that come fall, and the Norwegian fall persuades you to stay indoors...

Downloads are at the usual place: https://www.dayturn.com/viewer/index.php?resources/



Reply all
Reply to author
Forward
0 new messages