|
Viewing 1 to (7 Total) SSL/TLS question for Hugh |
Total Posts: 204
Joined: November 28, 2011
|
Hi Hugh,
I am testing a theory that we can have all the ndll's built to support both armv6 and armv7 in one for the iOS platform, but I have run into a challenge compiling SDL from source.
The SSL support appears to depend on axTLS. The source is readily available, but appears not to readily support being built on OS X. being that I am building for iOS I happen to be on a Mac.
So, my question is, do I indeed need axTLS built in order to correctly build the SDL libs for iOS? I am using "make OS=iphoneos" and it runs happily until it gets to building libcurl, which goes until this:
ar -cr libcurl.iphoneos.a ... (rest removed for brevity.. list of .o files)
ar: ../../axTLS/crypto/aes.o: No such file or directory
ar: ../../axTLS/crypto/bigint.o: No such file or directory
... (rest removed for brevity, bunches of axTLS files it's looking for but cannot find)
I attempted to grab axTLS and put it at the same level as nekonme, hxcpp, and sdl-static where it appears it is looking but it appears not to be happy being built in an OS X environment. I'm sure that's not the case, but it appears that way on the surface.
The SDL make process seems to truck along where it left off with another "make OS=iphoneos" but logically the aforementioned errors suggest to me the resulting libcurl would be missing critical aspects of SSL support... right?
Thanks, cheers!
Patrick
Tags:
Posted on February 22, 2012 at 5:38 PM
|
|
|
Total Posts: 547
Joined: October 07, 2011
|
Re: SSL/TLS question for Hugh
Hi,
The axTLS code should come with the sdl-static project.
You may need to update the svn version to get the new code.
Hugh
Posted on February 22, 2012 at 7:25 PM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: SSL/TLS question for Hugh
Hugh,
Thanks for the reply. I'm sure I'm simply missing something. I do see there is a src/tars/axTLS but this is the same I had downloaded from sourceforge; it appears to only enjoy being built for Linux, Cygwin, or Win32 based upon the neat curses UI that appears upon make. Is there a way to build these sources for OS X or is that somehow unnecessary?
Interestingly, although the libcurl build is looking in ../../axTLS/crypto for aes.o, bigint.o, crypto_misc.o, ..., etc., I see these are in src/ssl/curl-7.21.4/lib/ in sdl-static according to the SVN mainline (http://sdl-static.googlecode.com/svn/). Sorry to be a bother but I have to admit I am curious how you built these, is it enough to build them on a Linux or Windows machine in such a way that the resulting libs are usable for building libcurl for iOS (or Android, or WebOS, or ...)?
I happen to be using OS X 10.7.3 with the iOS 5.0 SDK.
I will try for fun making an axTLS/crypto folder containing all the libs in question to see what it does. Maybe this is just a mapping issue between ../../axTLS/crypto and src/ssl/curl-7.21.4/lib/?
Cheers and thanks again,
Patrick
Posted on February 22, 2012 at 9:04 PM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: SSL/TLS question for Hugh
It does appear it is simply an issue with the configs and the way my 'make' is interpreting them.
It occurs identically for the ogg build as it does for curl. The configs/ogg_makefile says:
OGG_SRC := src/bitwise.c src/framing.c
OGG_OBJS := $(OGG_SRC:%.c=%.o)
but make is in src/libogg-1.1.3 when it builds bitwise and framing so they end up there instead of in src where the config tells it to look, so we get this error:
ar -cr libogg.iphoneos.a src/bitwise.o src/framing.o
ar: src/bitwise.o: No such file or directory
ar: src/framing.o: No such file or directory
This is analogous to the issue with curl, caused by this in configs/curl-ssl-makefile:
CURL_OBJS := $(CURL_SRC:%.c=%$(SS_OBJEXT))
since CURL_SRC entries all point to $(AXTLS)/crypto/, it will look there for the .o files even though it happens to be in src/ssl/curl-7.21.4/lib/ when it builds them.
I would be happy to get these configs sorted out and post a diff if that would be helpful. Unless you have this working locally?
Patrick
Posted on February 22, 2012 at 10:29 PM
|
|
Total Posts: 547
Joined: October 07, 2011
|
Re: SSL/TLS question for Hugh
Hi
I guess it worked for me at some stage, so maybe it is a compiler version thing?
I would accept a patch though 
hugh
Posted on February 23, 2012 at 4:48 AM
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: SSL/TLS question for Hugh
It looks like this is an issue which appears if you try to compile for "armv6" and "armv7" at the same time.
I just made some small modifications to my makefile, using an $(ARCH) variable. I was able to compile for armv6 first, then armv7, and to use "lipo" to package them together into one fat static library:
lipo -output libz.iphoneos.a -create -arch armv6 libz.armv6.iphoneos.a -arch armv7 libz.armv7.iphoneos.a
This may be a good solution for SDL static, and might be handled more elegantly (since I'm not real experienced with makefiles). If it were simpler to support in HXCPP, I might suggest that we build for armv6+armv7 by default for iOS, but if we are going to move to OpenGL ES 2.0 this may be moot, since we would need armv7 only, anyway.
I vote to store "fat" libraries in sdl-static, and at least support an "armv6" flag in HXCPP:
<flag value="armv6" if="armv6" />
<flag value="armv7" unless="armv6" />
This provides the ability to compile for armv6 on demand, which could be linked by hand for a release. By default, however, we'll at least support armv7, which is a requirement to target iOS 4.x or 5.x as the minimum OS, and which is the only device architecture used by default in newer copies of XCode.
(I can gladly share my "fat" versions of the sdl-static libraries, but that probably isn't necessary?)
Posted on February 23, 2012 at 11:14 AM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: SSL/TLS question for Hugh
yes indeed that is the case, but only for libcurl and ogg. I developed a workaround but the armv6 portion stopped at freetype.
Building solely for armv7 went on without issue and armv6 died just like the combined build, at freetype.
I am proceeding with armv7 ndll's. I suspect the freetype issue arose due to the 5.0 SDK (vs. the 4.2 SDK you and Hugh are using). Since the 5.0 SDK has been out as the official production release for a good long while, it might be good to standardize on that because that will tend to be what developers will be using.
I haven't even gotten to the new "app store" Xcode that installs in /Applications, marking the end of the /Developer folder.. That is going to present some wrinkles we're going to encounter sooner or later (probably sooner).
Cheers all,
Patrick
Posted on February 23, 2012 at 11:41 AM
|
