Error compiling iOS app with Flash Library Symbols

[CSAStar]

Problem Description

Using ADT on Mac, am attempting to build an ipa file for iOS. This always used to work fine with SDK 33, but using latest 50.2.3.6, I'm getting an error during compilation. I'm using SWCs exported from Flash Library symbols, so was wondering if there has been a change to how symbols are handled.

The error that appears on Terminal:

ld: Assertion failed: (entry && "fillActivationTargetsFromFiles must be only called for files whose atoms were already added to the symbol table"), function flattenAndFillUndefinesFromFiles, file AtomSymbolTable.cpp, line 1027.

Compilation failed while executing : ld64

Thanks

[ajwfrost]

Hi

Actually this is a failure within the linker itself .. Apple updated this for Xcode 15 and there are problems with this linking the 'stub' library files that we generate. The workaround at the moment is to pass in a "platformsdk" option to ADT, giving it the path of your iPhoneOS SDK e.g.

-platformsdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk

(or you can set the iOSPlatformSDK option in the configuration file, or using AIR SDK Manager..)

We've got a build of the LLVM linker that seems to work better - and means we can support Xcode 14 style objective-c object files even on Windows - and will be pushing that out along with the new Xcode/iPhoneOS SDK support shortly.. there's a preview available from https://transfer.harman.com/link/BxsZukLF5pKkU6XKAzcVO6

thanks

[CSAStar]

Cheers, that's done the job! Looking forward to the fixes, improved Windows support for iOS apps sounds excellent.

[BMGMobile]

Hi,

We have applied the above patch to SDK 50.2.3.6 and we are getting an LLVM error when attempting to build an iOS Ad Hoc image on Windows 10 22H2 on a 64-bit machine with 32GB of memory.

llvm_error.txt (some details of the above details have been anonymized)

Is this something you are able to fix or is this an error we should report to the LLVM project?

Thanks.

Edit: We checked SDK 50.2.3.4 and it does not have this issue.

[ajwfrost]

Interesting @BMGMobile -> sadly I don't think we thought to keep the debug files for these builds of ld64, but I'm curious as to the out-of-memory thing, We can check whether there are any artificial limits being included here, but we can also just provide a debug build of the linker since that should give more details... I'll try to get an updated version uploaded here.

[FliplineStudios]

I would be interested in a version to try too -- I just tried the download link above to patch 50.2.3.6 but the download link has expired.

I also noticed on the Apple developer forums that there is a -ld_classic flag added to Xcode 15 to force it use the original linker instead of the new ld_prime, not sure if that's of any use though!

[ajwfrost]

@FliplineStudios extended link: https://transfer.harman.com/link/Brh2YO2NAELPL99TZbgimo

I have just noticed that on macOS I have both "ld" and "ld-classic" under /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin So we could perhaps adjust the path we use currently (/usr/bin/ld) .. but we'll probably just settle on using LLVM.

thanks

[FliplineStudios]

Thanks, I'm actually getting a different error using this llvm patch with 50.2.3.6 (on Windows 10 as well):

unexpected failure: not a MachO binary
java.io.IOException: not a MachO binary
        at com.adobe.air.ipa.MachoSigner.sign(MachoSigner.java)
        at com.adobe.air.ipa.MachoSigner.sign(MachoSigner.java)
        at com.adobe.air.ipa.IPASigner.signMacho(IPASigner.java)
        at com.adobe.air.ipa.IPAOutputStream.finalizeSig(IPAOutputStream.java)
        at com.adobe.air.ApplicationPackager.createPackage(ApplicationPackager.java)
        at com.adobe.air.ipa.IPAPackager.createPackage(IPAPackager.java)
        at com.adobe.air.ADT.parseArgsAndGo(ADT.java)
        at com.adobe.air.ADT.run(ADT.java)
        at com.adobe.air.ADT.main(ADT.java)

This project builds fine with 33.1.1.935 and installs correctly with its cert/profile in that build, so I don't think it would be an issue with the certificate... (EDIT: Also builds and installs fine with 50.2.3.4)

[FliplineStudios]

I'm getting the same "not a MachO binary" error with the llvm patch after removing all of the ANEs in the app (wanted to make sure that wasn't a factor).

Also should clarify this is an ad-hoc build, using a new distribution certificate and ad-hoc provisioning profile (which do work correctly on 50.2.3.4 and can be installed and run on device with that version). And this is on Windows 10, 22H2.

If there's anywhere I can look for error logs or more information to share just let me know!

[ajwfrost]

I don't suppose you get the binary being created there still and left unsigned? That error message comes out if it doesn't have the right signature in the first four bytes of the file... there's a possibility that there's a different endianness perhaps, although I can't see any information about LLVM handling this differently from Apple. Or else something fairly major has gone wrong..

If you see the binary left there (maybe as a temporary file still, starting with "aot") it would be great if we could take a look at it, or if you'd be happy uploading the whole project (or minimal SWFs/XML to get this to build with this error) it would be even more helpful... https://transfer.harman.com/requests/PeqiUOT49DMm6OxVN0dr54

thanks

[FliplineStudios]

Strangely I just tried on my home PC (working from home today), and the exact same files and SDK will build correctly on this PC! When I'm back in the office tomorrow I can upload the whole project and the leftover output when packaging there (I believe there is a folder starting with "AOT" left after it fails).

Is there anything configuration-wise that would make a difference with why one PC would package and sign correctly, and the other wouldn't? They both have the same 50.2.3.6 SDK with the llvm patch, and same files and certificates copied over (I copied all of these from the work PC to the home PC), I believe both using Java 11.0.13, both Windows 10 22H2, using the same adt command in a bat file to package...

[FliplineStudios]

@ajwfrost I just sent files for our project where this is happening -- there was an "AOTxxxx.tmp" folder generated in the directory while packaging, but after the "not a MachO binary" error it automatically cleaned up that tmp folder (and no ipa was generated), so I didn't have anything to attach for that. If there's anything else I can run/test/check/etc. just let me know!

[FliplineStudios]

@ajwfrost I've also tested with 50.2.3.7 and .8 SDKs and I'm getting the same "not a MachO binary error", but I think I've narrowed down where is issue is: On the PC where it can't build, all of the project files are on an external mapped network drive, and the adt package command is called from that folder on the network drive. If I copy all of the project files over to a local drive and attempt to package it there, it seems to package correctly. (AIR SDK is installed locally on main C drive in both cases, it's just a difference of where the project files to be packaged are).

For reference, I'm running the package command within the project folder so all paths are relative for what is to be packaged, and pointing to the absolute path of adt (you can see the exact setup in the compile_script.bat in the files that I had sent).

Is there anything with the new LLVM implementation that requires the project folder to be on a local drive vs. a network shared drive? It never seemed to make a difference with the old implementation...

[ajwfrost]

@FliplineStudios thanks for spotting that - we had tried it here but couldn't reproduce it.

So do you mean, a network drive that is mapped to a drive letter, so you're locally running on e.g. q:\testapp which may be mapped to \\servername\projectfolder\testapp, and then using relative folders for the application files?

I'm not aware of any limitation here from LLVM but it sounds like there must be! With this clue, let me see whether we can reproduce it and then I hope we should be able to address it!

thanks

[FliplineStudios]

@ajwfrost That's correct, we have a network drive in a NAS (\\fliplinedrive) that we've mapped to L:, so our project to package is located in L:\games\appname\compiler_ios and I'm running adt -package from that folder where all of the project files are located.

So something like: adt -package -target ipa-ad-hoc -storetype pkcs12 -keystore ../certs/mycert.p12 -provisioning-profile ../certs/adhoc.mobileprovision output.ipa myapp.xml myapp.swf Assets.car LaunchScreen.storyboardc appicons -extdir Extensions

Thanks for checking it out!

[ajwfrost]

We tried setting up this scenario, but still couldn't reproduce it .. I think we may need to provide an updated LD64.exe file to try to (a) add some debug info, and (b) ensure that we can check the output binary... Let me get someone to create this and I'll upload it here.

thanks

[FliplineStudios]

Okay thanks! I also just checked output in the Troubleshooting tab of AIR SDK Manager, but it doesn't look any different between a successful and unsuccessful package there, aside from "Unexpected failure: not a MachO binary" at the end. Also if you'd like me to open a separate issue for this (since it seems to related to the network drive?) let me know.

[boatbmg]

@ajwfrost Greetings! This is a follow-up of the comment by [BMGMobile]. With [AIR 50.2.4.4] the LLVM ERROR: _beginthreadex failed: Not enough memory resources are available to process this command. (0x8) is still happening. Any ideas/supports would be much appreciated!