[quake3] Mac Universal Binaries

Tue Apr 10 00:19:17 EDT 2007

Man, I'm FRICKIN desperate, I've been at this the whole entire day
(Yeah, I had no life today, been working on this since 11 AM to now, 9
PM), and I still can't figure it out. I've done so much I don't even
want to talk about it, or I don't even know if I could remember it
all. Basically I looked for universal binaries for my dependencies,
didn't find any, so then I rebuilt the libraries with:

env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
-arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure
--disable-dependency-tracking

This supposedly gave me universal libraries, and it did, for most
things, as I was able to check with the file command. However, some
things didn't come up as Universal. I then went ahead and found Fink
and a Fink developer told me I wasn't able to download i386 or
Universal Binaries, but he showed me the actual repository from where
I simply wget'd the debian packages of the things I needed. I then
extracted them using ar -x blah.dpkg and then tar xvzf'd the
data.tar.gz archive and found the libraries within the sw/lib folder.
I then used lipo -create thei386lib.a theppclib.a -output
theuniversallib.a on every library I needed. After finishing this, I
put them in the code/libs/macosx folder and re-added
-L$(PWD)/code/libs/macosx to the LDFLAGS for the Mac instruction set
in the Makefile. Well, things wouldn't work but eventually they did
and I was so happy. I went ahead and integrated support for updating
Mac binaries in my personal updater script (Has nothing to do with the
source tree), then after finishing a while later I went to re-build
the source and I got errors, thing is I didn't change anything.

However, after some thought I remembered that on Linux I commited some
changes to the Makefile accidentally. What happened was, I hadn't
commited the Mac changes because I wanted to make sure my Linux
checkout was nice and clean so there wouldn't be any conflicts. In the
svn status I saw the Makefile which I thought I hadn't changed...but I
did it commited anyways because I figured it was nothing, and I was
all hyped up that it worked so I commited anyways. I then commited the
Mac version (It didn't complain about conflicts, so I didn't know
anything about anything). After a while I re-built it and that's when
I got errors, and like I said earlier, that's when I remembered all of
this. So I went ahead and looked at the differences between the
revisions [ http://svn.jorgepena.be/viewvc/viewvc.cgi/trunk/Makefile?r1=24&r2=25
], that's also when I realized that the problem was probably having to
do with subversion because for example those lines 37 & 38, I didn't
do in that commit. So I went ahead and played around with it, removed
that, etc. etc. to no avail. After doing something else (I don't
remember what) it worked. So I wanted to be sure, and without changing
anything at all, ran 'make clean' and ran the mac make bash script
again, that's when I got the errors again:

ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/libgcc_s.1.dylib referenced
from: /Users/bryantcarrasquillo/tip/src/code/libs/macosx/libz.dylib
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)
ld: Undefined symbols:
_strerror_r
_sscanf$LDBLStub
_SSL_pending
_sprintf$LDBLStub
_dlclose
_dlopen
_dlsym
_DES_ecb_encrypt
_DES_set_key
_DES_set_odd_parity
_MD4_Final
_MD4_Init
_MD4_Update
_MD5_Final
_MD5_Init
_MD5_Update
_RAND_bytes
_ASN1_STRING_data
_ASN1_STRING_length
_ASN1_STRING_to_UTF8
_ASN1_STRING_type
_CRYPTO_cleanup_all_ex_data
_CRYPTO_free
_CRYPTO_malloc
_ENGINE_by_id
_ENGINE_finish
_ENGINE_free
_ENGINE_get_first
_ENGINE_get_id
_ENGINE_get_next
_ENGINE_init
_ENGINE_load_builtin_engines
_ENGINE_load_private_key
_ENGINE_set_default
_ERR_error_string
_ERR_error_string_n
_ERR_free_strings
_ERR_get_error
_ERR_remove_state
_EVP_PKEY_copy_parameters
_EVP_PKEY_free
_EVP_cleanup
_GENERAL_NAMES_free
_PKCS12_PBE_add
_PKCS12_free
_PKCS12_parse
_RAND_add
_RAND_egd
_RAND_file_name
_RAND_load_file
_RAND_status
_SSL_CIPHER_get_name
_SSL_CTX_callback_ctrl
_SSL_CTX_check_private_key
_SSL_CTX_ctrl
_SSL_CTX_free
_SSL_CTX_load_verify_locations
_SSL_CTX_new
_SSL_CTX_set_cipher_list
_SSL_CTX_set_default_passwd_cb
_SSL_CTX_set_default_passwd_cb_userdata
_SSL_CTX_set_verify
_SSL_CTX_use_PrivateKey
_SSL_CTX_use_PrivateKey_file
_SSL_CTX_use_certificate
_SSL_CTX_use_certificate_chain_file
_SSL_CTX_use_certificate_file
_SSL_SESSION_free
_SSL_connect
_SSL_free
_SSL_get1_session
_SSL_get_certificate
_SSL_get_current_cipher
_SSL_get_error
_SSL_get_peer_certificate
_SSL_get_privatekey
_SSL_get_shutdown
_SSL_get_verify_result
_SSL_library_init
_SSL_load_error_strings
_SSL_new
_SSL_peek
_SSL_read
_SSL_set_connect_state
_SSL_set_fd
_SSL_set_session
_SSL_shutdown
_SSL_write
_SSLeay
_SSLv23_client_method
_SSLv2_client_method
_SSLv3_client_method
_TLSv1_client_method
_UI_OpenSSL
_X509_NAME_ENTRY_get_data
_X509_NAME_get_entry
_X509_NAME_get_index_by_NID
_X509_NAME_oneline
_X509_STORE_CTX_get_current_cert
_X509_free
_X509_get_ext_d2i
_X509_get_issuer_name
_X509_get_pubkey
_X509_get_subject_name
_X509_verify_cert_error_string
_d2i_PKCS12_fp
_sk_num
_sk_value
make[1]: *** [build/release-darwin-ppc/tip.ppc] Error 1
make: *** [build_release] Error 2

Not only that, it varies, but it's always having something to do with:

ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/libgcc_s.1.dylib referenced
from: /Users/bryantcarrasquillo/tip/src/code/libs/macosx/blah.dylib

I have a feeling that it's because some of the libraries weren't
static by default and even though I'm not explicitly linking to the
dylib's they're being linked. I'm going to try again with pure static
ones, I'll have to do ask someone to build them for me though because
I just can't do it. Ahhh man, everything works on PPC but not Intel,
if this keeps up I'll just keep PPC until someone volunteers to do
Intel. Sorry for the long, pointless, boring message.

On 4/9/07, Tony J. White <tjw at webteam.net> wrote:
>  On Sat, Apr 07, 2007 at 09:43:54PM -0700, Jorge Peña wrote:
> > No problem, so it builds a UB right? With intel and ppc binaries in it? For
> > the dependencies, did you have Intel and PPC versions? Or did you just build
> > them and it worked? I'm pretty curious, I had the feeling I just had to get
> > the Intel versions of the dependencies and things would work, I'll try that
> > next time I get a chance to use my friend's Mac. You are building with
> > dependencies curl, ogg, and vorbis, right?
>
> cURL is included with Mac OS X, so we don't link to it by default.  It is
> dynamically opened at run time.  I've never tried building ogg support.
>
>  > Anyways, I'll keep at it, kind of difficult when I don't have a Mac. I'm
> > pretty sure just having Intel versions of the dependencies will work.
> > Someone was nice enough to build them for me (Some random guy in #mac).
> > Hopefully it works, I'm pretty sure it will because like I said before I had
> > dependencies it would build perfectly, and now that I have them it complains
> > about the library's architecture type, so hopefully this will solve it.
> > Thanks for at least responding, anyways.
>
> The easiest way to make universal binaries with dependencies is to link
> against a a .dylib that contains both architectures.  For
> an example, download the SDL source code and look at the file
> build-scripts/fatbuild.sh.  This is what we use to make the universal
> libSDL-1.2.0.dylib that is included with ioq3.
>
> -Tony
>
> >
> > On 4/7/07, Zachary Slater < zakk at timedoctor.org> wrote:
> > >
> > >Jorge Peña wrote:
> > >> Hey guys, you probably remember me asking about how to build on Mac,
> > >> well I got it and it's working perfectly! However, if you remember
> > >> correctly, I had to remove the i386 targets for the bash make script
> > >> because it wouldn't build. Well, it turns out that now someone else on a
> > >> Mac Intel wants a copy, so I at first figured that I would have to
> > >> re-build the whole thing on their computer, and well, they're not really
> > >> computer oriented and they might not be as happy to have me SSH into
> > >> their computer as my other friend would. So I asked if this was
> > >> necessary inside #mac freenode, and they said that if they are Universal
> > >> Binaries then they should work just fine. I was wondering how that was
> > >> so, so I looked here [  http://en.wikipedia.org/wiki/Universal_binary ],
> > >> I found out that basically it consists of binaries for both
> > >> architectures within the same 'package', and the host computer
>  > >> automatically chooses the correct binaries. I was wondering if it was
> > >> possible to build binaries for both architectures on PPC, and I read
> > >> this [  http://developer.apple.com/macosx/adoptinguniversalbinaries.html
> > >> ] which seemed to say it was possible. However I remembered that I
> > >> removed the i386/Intel targets in the make bash script (Not the
> > >> makefile, but the make mac bash script) because it wouldn't build. I
> > >> found a document from Apple that helps with building a universal binary
> > >> here [
> > >>
>  > >http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf
> > >> ].
> > >>
> > >> I think the reason that it didn't build last time was because I had PPC
> > >> versions of the dependencies (I remember it arguing about mismatching
> > >> architectures), so that's why I'm wondering if you guys know how to
> > >> build Intel versions of the dependencies. My other question is, am I
> > >> right in all of this? Does the ioquake3 Makefile usually automatically
> > >> create the Universal Binaries? I think so, because I think I remember it
> > >> building without complaining before I added all the dependencies. I'll
> > >> try to look for 'Universal Binaries' of the dependencies in the
> > >> meantime, but I first want to make sure I'm right in all this before I
> > >> go through more of a waste of time. Thanks guys I really appreciate it!
> > >
> > >
> > >Sorry I can't say much more besides that I use make-macosx-ub.sh and it
> > >works perfectly.
> > >--
> > >- Zachary J. Slater
> > >zakk at timedoctor.org
> > >zacharyslater at gmail.com
> > >
>