Fire projects can't compile due to Mono library issue (32-bit) in Catalina

I get this error building in macOS Catalina for any project I created before, and even new ones.

E: Fatal Error: /Users/xxx/Applications/Fire.app/Contents/Resources/Mono/lib/../lib/libmono-native.dylib assembly:<unknown assembly> type:<unknown type> member:(null)

I used another Macbook with macOS Mojave to install Fire and saw the 32-bit warning on libmono. I installed an external mono library but it doesn’t use it for builds. Is there a workaround for the meantime to use an external mono library to run builds?

Hmm, that’s curious. Fire is fully 64-bit, as is its embedded Mono, has always been. And it’s running fine for me on Catalina Beta 2. Any project fails with this error? Can you send me the complete “Diagnostic” level build log?

thanx!
marc

It fails running builds with both Swift Android and Swift macOS/iOS projects on my Catalina beta 2 Macbook - old and new ones. I am just not sure if I was able to create the other older projects in a previous Fire build in Catalina beta 1 or on Mojave.

The same .2415 Fire app installed on my other Macbook builds all projects fine so far (clean slate from project templates).

How do I get the “Diagnostic” level build log? Sorry I’m relatively new to using the Fire app.

You can change this in the Preferences dialog (⌘.), at the very top of the third tab:

Yeah, it wouldn’t matter if the project was new or old, if this is a mono bitness issue… I’ll investigate some more on my end later today when I’m back on the machine I have Catalina on…

I don’t see any difference in the Build Log when I switched to Diagnostic but I missed to include some other lines in the log.

/Users/xxx/Applications/Fire.app/Contents/Resources/Mono/bin/mono /Users/xxx/Applications/Fire.app/Contents/Resources/EBuild.exe "--setting:Elements:ToffeeSDKFolder=/Users/xxx/Applications/Fire.app/Contents/Resources/Toffee SDKs" "--setting:Elements:IslandSDKFolder=/Users/xxx/Applications/Fire.app/Contents/Resources/Island SDKs" "--setting:Elements:GothamXmlFolder=/Users/xxx/Applications/Fire.app/Contents/Resources/Gotham XMLs" "--setting:Elements:ReferencePathsXMLFolder=/Users/xxx/Applications/Fire.app/Contents/Resources/Reference Paths with Data Abstract Trial" --setting:Elements:IslandLddExePath=/Users/xxx/Applications/Fire.app/Contents/Resources/lld --setting:Elements:ToffeeHelperExePath=/Users/xxx/Applications/Fire.app/Contents/Resources/ToffeeHelper /Users/xxx/dev/org.sample.FireAndroidSample/org.sample.FireAndroidSample.sln --logger:fire --configuration:Debug --debug --statistics --verbosity:diagnostic --xml:/var/folders/2l/cqk15d_n4r70p3w0n6kml4ph0000gp/T/org.sample.FireAndroidSample.fire.xml --build --setting:TreatFixableErrorsAsWarnings=True
RemObjects EBuild. An open source build engine for Elements and beyond.
Copyright RemObjects Software 2016-2019. All Rights Reserved. Created by marc hoffman.
Version 10.0.0.2415 (develop) built on bajor, 20190621-131308. Commit a346ebd.

E: Fatal Error: /Users/xxx/Applications/Fire.app/Contents/Resources/Mono/lib/../lib/libmono-native.dylib assembly:<unknown assembly> type:<unknown type> member:(null)

Hope that helped in some way.

Odd. I’ll see what I can do here…

Reproduced, it fails with the embedded compiler, it works fine with the external compiler (see https://docs.elementscompiler.com/Fire/Setup/Mac/ExternalCompiler/, but note that I ran into some Gatekeeper issues with the external compiler installation on Catalina that I have yet to investigate fully. You will need to manually de-quarantine libRemObjects.Elements.LLVM.dyllib).

Now to find out why the embedded compiler/mono fails… :frowning:

 /Users/mh/Code/Fire/Bin/Build/macOS/Fire.app/Contents/Resources/Mono/bin/mono /Users/mh/Code/Fire/Bin/Build/macOS/Fire.app/Contents/Resources/EBuild.exe

Unhandled Exception:
System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.ConsoleDriver' threw an exception. ---> System.DllNotFoundException: /Users/mh/Code/Fire/Bin/Build/macOS/Fire.app/Contents/Resources/Mono/lib/../lib/libmono-native.dylib assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) Interop+Sys.Stat(byte&,Interop/Sys/FileStatus&)
  at Interop+Sys.Stat (System.ReadOnlySpan`1[T] path, Interop+Sys+FileStatus& output) [0x00028] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0x00007] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.IO.FileSystem.DirectoryExists (System.ReadOnlySpan`1[T] fullPath, Interop+ErrorInfo& errorInfo) [0x00000] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.IO.FileSystem.DirectoryExists (System.ReadOnlySpan`1[T] fullPath) [0x00000] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.IO.Directory.Exists (System.String path) [0x0001e] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.TermInfoDriver.SearchTerminfo (System.String term) [0x00044] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.TermInfoDriver..ctor (System.String term) [0x0004b] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.ConsoleDriver..cctor () [0x0004d] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding, System.Text.Encoding outputEncoding) [0x00007] in <c960d00aa53f46b89bb10964fa2ccbed>:0 
  at System.Console..cctor () [0x0007d] in <c960d00aa53f46b89bb10964fa2ccbed>:0 

definitely looks like a problem with the mono executable that’s embedded inside Fire :(.

Best I can do is try to build a newer version of Mono for embedding and see if that one solves the problem… Not sure what Apple did this time to break this :(. I’ll try to get that in for tomorrow’s update, but I cannot promise.

In the mean time, external mono and external compiler will be the best workaround.

This one is most likely an unrelated issue, can you give me more details on this? What does it say and where, exactly?

Since Fire is a 64-bit executable, and has been from day 1, seven years ago, libmono 100% sure is 64-bit, else all of Fire would never have worked ;). This must be something else (also, I’ve never seen a warning on Mojave or Catalina, myself)

Thanks for looking into it. Will try the external compiler instructions in the link you provided and see if I can sort it out myself.

1 Like

Good news, I just rebuilt the very latest Mono from scratch, and it seems to have fixed that error. Trying to embed it now.

Confirmed fixed for tomorrow’s build. If you’d like, I can send you a copy ahead of time — what’s your login name on remobjects.com?

—marc

I’m trying to reinstall the app on Mojave but the pop-up doesn’t show up again. It does look like this screenshot (the usual pop-up for 32-bit apps, e.g. when launching Steam app for the first time)

P.S. sorry I’m not sure how to properly quote replies to posts but this is the answer to your question regarding 32-bit warning for libmono.

Sent you a DM of my login name.

I tried downloading the ExternalCompiler but it doesn’t allow me…probably because it needs me to have a subscription. No worries, if you have fixed it then I’d just probably wait for the new release. Thanks Marc for looking into this.

Ah yes, I think we currently only have the full Fire download available for free; I’ll look into fixing that. Mean time, I have uploaded a new Fire to your Personal Downloads folder now.

Odd. I’ve seen thiose, of course, but I;ve never seen it for Fire, or have anyone else report it (and Fire is 64-bit, it’s built with Elements, which never even bothered to introduce 32-bit support for macOS, because 64-bit already was the standard back ~10 years ago when we first started on Mac support ;).

If you just select text anywhere on the page, you’ll see “quote” button pop up:

It’s probably unrelated anyway, and if you’d fixed the issue it may indeed be a non-issue :slight_smile:

Cool. But only if I know where to find the correct Personal Downloads folder :smiley: Is this the same page if I open https://secure.remobjects.com/portal/downloads/elements.aspx ? I see 2415 builds there.

P.S. and hey, I learned to quote :laughing:

1 Like

https://www.remobjects.com/portal/downloads/personal, should be linked from the root Portal page.