Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undefined symbols for arm64 SDLUIKitDelegate #6

Open
niaccurshi opened this issue Jan 31, 2016 · 13 comments
Open

Undefined symbols for arm64 SDLUIKitDelegate #6

niaccurshi opened this issue Jan 31, 2016 · 13 comments

Comments

@niaccurshi
Copy link

Hi, I'm using this extension with an android and iOS app. Android works just fine but iOS has an issue when compiling. It comes up with an error of:

Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_SDLUIKitDelegate", referenced from: ltmp27 in libfacebook.a(a5504ceb_SDLUIKitDelegate+ExtnesionFacebook.o) l_OBJC_$_CATEGORY_SDLUIKitDelegate_$_ExtensionFacebook in libfacebook.a(a5504ceb_SDLUIKitDelegate_ExtensionFacebook.o)

Any idea what might be the cause of this? Something in my setup, or something with the code?

@Tomobodo
Copy link
Contributor

Wich version of openfl / lime do you use on mac ?
Do you use a legacy version when SDL wasn't the backend yet ?
Try to use the legacy branch maybe.

@niaccurshi
Copy link
Author

Thanks for the quick reply, everything is on the current latest version for openfl and lime. I've not had to use legacy on ios before, is it a case of using the same -Dlegacy flag as Android do you know?

@Tomobodo
Copy link
Contributor

By legacy i meant previous version of lime when SDL was not yet the system backend.
If you use last lime and openfl with master branch of the extension it should be fine.

I see in lime's changelog that sdl have been updated, maybe it's what causing the issue.

I understant from the error you linked that the SDLUIKitDelegate class is not found, as if it changed name with the new version or got remove, I can't tell yet. It's strange.

Sadly I don't have access to a mac anymore, I don't have my own and won't be able to buy one before weeks so I won't be able to fix this rapidly.

One thing you can try is to set lime to 2.8.3 and try to run again. If it compile then the error probably come from that sdl upgrade.

I'm sorry, I can't try to reproduce and fix this right now.

@niaccurshi
Copy link
Author

I'll give that a go, A clean build of the project changed the problem from arm64 to armv7 but I'm assuming that it's essentially the same issue. I'll roll back lime and give that a go

@niaccurshi
Copy link
Author

Unfortunately setting lime to 2.8.3 wasn't a solution in this case

@niaccurshi
Copy link
Author

If there is a way that I can somehow help to narrow down this issue by proxy I am happy to do what I can to work out what's going on? I'm happy to poke around and try some things, I understand you personally can't look to reproduce at the present time but my client is looking for solutions ASAP. Give me some direction and I can head off and investigate ;)

@Tomobodo
Copy link
Contributor

Tomobodo commented Feb 9, 2016

Hello,

sorry for not answering this week.

I got a mac and triied to reproduce your problem on a fresh new install but couldn't reproduce it, no linking error. The only error I got was a code signing error 'cause I don't have any iDevice yet, but normaly those errors occurs after linking I think.

I use :

  • hxcpp 3.2.205
  • lime 2.9.0
  • openfl 3.6.0

ios sdk 9.2
and the last commit on the master branch of this extension.

I really can't see why you have this error.
I'll try to get a cheap iPhone and let you know if I found anything.

Did you rebuild lime from source or the extension maybe ?

@niaccurshi
Copy link
Author

Hi, thanks for taking the time. I'm going to go and double check what I'm compiling against on the Mac and hopefully this'll just turn out to be some dumb thing I've overlooked (I'm not experienced with OpenFL Mac development as I'm sure you've gathered!) I'll leave another message once I have some more information as to what I'm using.

@Tomobodo
Copy link
Contributor

Hello, hope you found a solution.
Just in case, I finally got an iPhone and just tested... no linking error on my side.
I don't know how to reproduce your problem but in my opinion the problem comes from your environment.

Check you use last lime (or at least a version based on SDL) and you use the master branch of this repo.
then rebuild the extension using lime rebuild facebook ios.
then lime update ios and haxelib run facebook project.xml.

this should work unless you use -Dlegacy to build your project

If you use -Dlegacy, switch to the legacy branch of this repo and rebuild the extension.

@mastef
Copy link

mastef commented Jul 22, 2016

openfl: [3.6.1]
hxcpp: [3.3.49]
flixel: [4.0.1]
lime: [2.9.1]

Just ran into this when building for iOS simulator, and we're also using -dLegacy.

Ld build/Debug-iphonesimulator/Game.app/Game normal i386
    cd /game/export/ios
    export IPHONEOS_DEPLOYMENT_TARGET=8.1
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"

    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
     -arch i386
     -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.3.sdk
     -L/game/export/ios/build/Debug-iphonesimulator
     -L/game/export/ios/Game/lib/i386-debug
     -L/game/export/ios/Game/lib/i386
     -F/game/export/ios/build/Debug-iphonesimulator
     -F/usr/local/lib/haxe/lib/facebook/git/dependencies/ios
     -filelist /game/export/ios/build/Game.build/Debug-iphonesimulator/Game.build/Objects-normal/i386/Game.LinkFileList
     -mios-simulator-version-min=8.1
     -Xlinker
     -no_deduplicate
     -Xlinker
     -objc_abi_version
     -Xlinker 2
     -lstd
     -lregexp
     -llime-legacy
     -lfacebook
     -lApplicationMain
     -stdlib=libc++
     -ObjC
     -framework UIKit
     -framework OpenAL
     -framework OpenGLES
     -framework QuartzCore
     -framework CoreAudio
     -framework CoreGraphics
     -framework AudioToolbox
     -framework AVFoundation
     -framework Foundation
     -framework CoreMotion
     -framework MediaPlayer
     -framework FBSDKCoreKit
     -framework FBSDKLoginKit
     -Xlinker
     -dependency_info
     -Xlinker /game/export/ios/build/Game.build/Debug-iphonesimulator/Game.build/Objects-normal/i386/Game_dependency_info.dat
     -o /game/export/ios/build/Debug-iphonesimulator/Game.app/Game

Undefined symbols for architecture i386:
  "_OBJC_CLASS_$_SDLUIKitDelegate", referenced from:
      anon in libfacebook.a(520600ac_SDLUIKitDelegate+ExtensionFacebook.o)
      l_OBJC_$_CATEGORY_SDLUIKitDelegate_$_ExtensionFacebook in libfacebook.a(520600ac_SDLUIKitDelegate+ExtensionFacebook.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Building on Mac, and since it's flixel it has to be on legacy. Gonna try now the legacy branch

@mastef
Copy link

mastef commented Jul 23, 2016

@TBaudon works with legacy branch. Need any help debugging this?

@Tomobodo
Copy link
Contributor

Hello, thanks for your help.

I don't think this is a bug actually.

As specified in the readme, if you use the ios legacy backend you have to use the legacy branch of this extension.
Using ios legacy backend means using the -dLegacy tag when building for ios, maybe it's not clear enough in the readme, I'll change that.

The problem is, legacy backend used a nme based class to handle every system related stuff, but then on the next lime version, SDL was used to replace this part. So I made two branch, one to use lime backend on legacy, and one to use sdl on master.

The legacy branch is not outdated, it's called legacy to correspond to the lime backend's name.

I don't really know how to do it in another way.

Maybe at compile time, the extension would need to check wich backend is in use and generate the corresponding categorie class...

It's easier to maintain two branch I think.

@mastef
Copy link

mastef commented Jul 24, 2016

Ah @TBaudon that makes sense!

In haxe there's

#if openfl_legacy

#end

Maybe that would be better, as the legacy branch doesn't have the recent improvements added ( such as java version forcing and string = null setting )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants