Having some troubles with 64bit iOS builds

Help
#1

Hi,

We are currently using a fairly old version of Openfl which has been working out great for us until today, when I started looking into compiling 64 bit versions for iOS.

Joshua, I’m kinda looking in your direction here a lot, I know you’re the guy to ask about this. I looked at all your forum posts about the changes you made to support 64 bit version, I have manage to incorporate a lot of the changes into our version, but alas I need some help :frowning:

I can get hxcpp to build 64 bit versions of libraries, so all the standard libraries (std, regexp, zlib) are coming out ok. However I tried to compile Lime and got a problem with zlib not being set up correctly for 64 bit. So I researched and I think I found a solution which involved changing curlbuild.h. However, lime uses a bunch of third party libraries in the lime-build folder, and I think I have to recompile these (using the changed curlbuild.h) as 64 bit libraries to make them work in a 64 bit version of Lime.

So I tried going into the src directory in lime-build, and there’s a lot of make file scripts to build for different platforms and architectures. However I tried to run (on a mac):

make OS=iphoneos

but I keep getting an error:

  cd ssl/curl-7.21.4/lib; make -f Makefile
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -DIPHONE=1 -D__IPHONEOS__=1 -O2 -I../../include/SDL12 -DSDL12 -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -Wreturn-type -Wunused-variable -fno-stack-protector -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk axtls.c -c -oaxtls.o -I../include -I../../../include -Ilib  -DHAVE_CONFIG_H -DCURL_STATICLIB  -I../.. -I../../axTLS/crypto -I../../axTLS/ssl -I../../axTLS/config -DUSE_AXTLS=1
    make[1]: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc: No such file or directory
    make[1]: *** [axtls.o] Error 1
    make: *** [ssl/curl-7.21.4] Error 2

I’ve tried with a few different parameters, I’m guessing eventually I’ll want to do:
make OS=iphoneos VER=8.1 ARM=64

Am I on the right lines here? It feels like I’m close, I just need to get these last things working.

Help here would be greatly appreciated!

Thanks,
Greg

#2

Hey Greg,

We moved to static builds for these dependencies as a part of rebuilding the Lime NDLL, it’s helped make it simpler to support multiple architectures and to make sure that builds don’t go stale.

You might consider borrowing code from the current Build.xml to pull in some of these dependencies statically, rather than building separately. The nice thing about this is that you’re sure you’re using the same HXCPP system for the build, which makes it simpler to resolve system paths for the compiler toolchain, reuse the same build flags, and other parts of the build.

However, this exact issue seems like it wants to use clang instead of GCC, or perhaps GCC is in a different place in the newer platform SDK? I would try taking hints from the HXCPP toolchain to see how it is setting this up.

Perhaps this could be replaced with xcrun gcc instead of gcc, might make a difference

#3

Thanks for the swift reply, I’ll take a look at what you’ve suggested and see if I can fix it. I appreciate the help a lot, thanks.

#4

You may have considered this already, but it sounds like you’re willing to invest a fair amount of time to get this working. Why not use that time to upgrade OpenFL? That way, not only will you get 64-bit binaries, you’ll get all the other features that OpenFL has added in the meantime. Plus, it’ll make any future upgrades that much easier.

#5

Thanks Joshua,

It was indeed just looking for gcc in all the wrong places. Of course now curl wont compile with the latest version of iOS SDK, so I’m trying to download an older SDK. I didn’t actually know much about makefiles before today, but now I know a whole lot more :wink:

player_03 - We’ve been using nme/openfl for a really long time, but we had to fork about 18 months ago - at the time we needed to add some extra stuff to get the results we needed at the time for a commercial project, at the time Openfl didn’t seem to support rotating text fields for example (I’m sure it’s moved on a huge amount since).

We could upgrade to the latest openfl, but it would mean a lot of hassle considering we have an engine at the moment which does everything we need (besides 64 bit versions, which should be working soon). Because we’re a business we need to get a super stable engine and just stick with it, even if it’s not completely up to date, as long as we can release commercial products. I’m sure one day we’ll look at upgrading to a current version, but we just don’t have the time right now.

Cheers guys.

#6

Just an update - got it working :wink: - 64bit builds are now working nicely. I realized pretty quickly that iOS SDK 6.1 can’t actually do 64 bit builds (duh)- so I had to use 8.1 and fix the issues with Curl, but it was actually pretty easy, and Curl was the only library that seemed to have any problems.

There was one weird thing though - calling system.capabilities.language() seemed to give a runtime error… it only happened when running on an actual iPhone 6 in 64bit. It seemed to suggest something in CFFI was doing it, but we dont use that function much, so I just disabled it for now.

Anyway, thanks for the help and support - it’s great to see OpenFL still going so strong!

Greg

#7

Hey Greg :smile:

If you have modifications, I’d be happy to see your diff if you would allow it, then I could try to be sure that we’re integrating the patches/changes and improvements that you’ve seen along the way. Rotating TextFields is supported now, but it sounds like you have other patches that might be helpful :smile:

Try this: :success:

https://github.com/openfl/lime/blob/master/legacy/project/src/iPhone/System.mm#L22-L34

#8

Thanks for that. Unfortunately the codebase we have for openfl isn’t on github any more, so it would be tricky to show you what we’ve done. It seems that OpenFL’s aim is to maintain as much compatibility with Flash as possible whereas our aim has been focused mainly on performance, so a lot of our fixes would probably break compatibility in favor of performance.

An example of this is the text rotation stuff. I did some changes to how Lime deals with bitmap caches, It seemed like whenever you drew text for example it was completely redrawing it in software, even if you were just changing alpha or rotating it. So I made it draw the software version with no transformation and then any rotations or color transforms (anything which can be done in hardware) are done in hardware. So you can have a text field which initially draws in software, but then if you rotate it or change alpha etc it will do all that in hardware.

That’s all well and good for what we want but I understand that could potentially break Flash compatibility, for example if you have a drop shadow on text, usually that would keep it’s orientation if the text rotates, but in our version it wouldn’t, but we dont mind since we wouldn’t ever do that, in fact we try to avoid using filters.

In any case, I’m sure you’ve fixed this, probably in a better way. I’m sure you’ve fixed most of the little things we’ve encountered along the way. We may have just fixed them in a way which is more geared towards what we need for our games.

Another example would be with the sound, about 18 months ago we were having some major issues with sound on Android - I think you’d just switched to using OpenAL for all sound, but there were a few problems (on Android). We were about to ship a game so we had to go back to having a native Java sound engine for Android, which works and we’re still using it. It’s not as elegant as having just one sound library across all platforms, but like I said, we had to literally release a game there and then.

If we come up against a problem I usually will check the Openfl github history to see if you’ve solved it before - a lot of times you have and there’s some very useful code.

Just out of interest, we had a strange bug the other day which we managed to fix, I’m betting you’ve already fixed it- it goes like this:

var pParentClip : MovieClip = new clip1();
var pChildClip : MovieClip = new clip2();

pParentClip.addChild( pChildClip );

trace( pParentClip.height );   // prints 100 for example
pChildClip.height += 100;
trace( pParentClip.height );   // still prints 100

In our case, setting the child’s height like this wasn’t updating the parent’s height immediately - the cache was being marked as dirty but wasn’t being rebuilt. Does this still happen in your version?

If I think of any more specific fixes I’ll check them.

Thanks,
Greg

#9

Hmm, I’m not sure about that one.

Your code doesn’t have to be on GitHub – either you could privately send me a full copy, or if you had an idea where it diverged, then maybe you could do a *.diff off that version, or do both – send a full copy, but let me know what version it probably diverged from.

TextField, specifically, was replaced with an implementation that uses drawTiles under the hood, which should be better, but I think TextField (in general) is something that can continue to improve

OpenFL is going to continue to grow in terms of Flash compatibility, but it is not meant to be a Flash emulator – so the point is not to choose compatibility over practicality and performance :smile: Also, the long-term arc is to move onto the Lime library as the base layer, which gives us the opportunity to hook into things at a lower level