How are you trying to access the extension? Are you accessing extension.iosaudio.IOSAudio from Haxe, or are you including OpenFLIOSAudio.h in a C++ file?
Ah- are you saying I should just change the first argument from “iosaudio” to “ios-audio” …?
Or that I should rename the ndll’s themselves?
As for the other issue (that you replied to on github), I can’t reproduce that behavior anymore. I think it went away after I rebuilt the extension with lime.
I changed the first Lib.load arguments to “ios-audio”, and rebuilt, but am now receiving the original error message again:
Classes/Main.mm:39:30: error: expected ';' after top level declarator
extern "C" int extension-ios-audio_register_prims();
^
;
Classes/Main.mm:78:21: error: use of undeclared identifier 'audio_register_prims'; did you
mean 'std_register_prims'?
extension-ios-audio_register_prims();
^~~~~~~~~~~~~~~~~~~~
std_register_prims
Classes/Main.mm:15:21: note: 'std_register_prims' declared here
extern "C" int std_register_prims();
^
Classes/Main.mm:78:17: error: use of undeclared identifier 'ios'
extension-ios-audio_register_prims();
Sorry, I feel like this has to be something super simple but I just can’t wrap my head around the full path/procedure that extensions use to name and identify everything.
The problem is that at some point, the extension creator switched from “iosaudio” to “extension-ios-audio,” and they didn’t update all the references. This inconsistency causes errors, and the hyphens cause more errors.
To avoid any more issues like this, I suggest reverting to “iosaudio,” removing “extension-ios-audio” entirely. Update include.xml and Build.xml, and hopefully the error in Main.mm will go away. (It looks like that line is generated automatically, and my guess is, it’s based on include.xml.)
If that still doesn’t fix it, it’s time for drastic measures. Rename the haxelib project itself, including the path in the .dev file. Search for the string “extension-ios-audio,” and replace any instances you find. Clear the extension’s ndlls, rebuild the extension, and do a clean build of your project.
Followed all of your suggestions, short of renaming the extension itself. This time I made it all the way to the linking phase before xcode kicked me out and complained about the register_prims line.
Sending another tweet to the author to see if he can shed some light on this.
“_extensioniosaudio_register_prims” referenced from _main in Main.o
symbol(s) not found for architecture arm64
I’m getting paranoid now, like I changed the name of something else I shouldn’t have changed while trying to fix this. The author responded on twitter with “the version on github is what I compile and use with twofold, so it does work, but that might be for my specific set of versions”
@player_03, any chance you have tried to install this extension yourself? I’d hate to think I’m making some huge mistake on my part that otherwise wouldn’t happen.
Sounds like you missed either include.xml or this line. The latter isn’t your fault: I didn’t mention it, and it wouldn’t have come up when searching for “extension-ios-audio” as I suggested.
Anyway, make sure the line in include.xml is <ndll name="iosaudio" if="ios" /> and the line in ExternalInterface.cpp is extern "C" int iosaudio_register_prims() { return 0; }.
They’d have to rename the ndlls by hand, but now that I look at it, that could be enough. It looks like Lime is smart enough to replace the hyphens automatically. (What version of Lime are you running? That line of code was added almost a year ago, and it ought to have prevented the “undeclared identifier” errors.)
If you really are using an older version, then you should be able to fix this by updating Lime, reverting to the official git repository, and renaming the ndlls. (You probably don’t need to rebuild the extension, since the ndlls are already built.)
Welp, I updated lime and was able to finally compile everything… but my app now crashes on startup with the message “primitive not found: lime_byte_array_init__4 Error Null Function Pointer”
I just did ‘haxelib update lime,’ was there anything I missed? Or is this some natural incompatibility with the old version of openfl?
I may have to cut my losses soon and set this aside. This is for a shipped product with a milestone deadline coming up in a couple of weeks : (
That’s what I was afraid of. I froze updates on this a while back to make sure I always had a stable version to work with.
I’m still a bit uneasy when it comes managing this stack of versions and dependencies.
If I update openFL and my game breaks, I can revert openFL with “haxelib set”, right?
Any other gotchas I need to be aware of?
