Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Xcode 2 project template

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Xcode 2 project template
Thomas Harte
Member #33
April 2000
avatar

Attached is a project template for Xcode 2 (created with 2.4.1, not tested with any other version) which, unlike the current Project Builder template does the following:

  • makes a universal binary

  • embeds the framework

When you unzip the file on Mac OS X, you get a single bundle (i.e. looks like a file in the Finder, is actually a folder with arbitrarily many files in it) named AllegroApp.xcodeproj. I expect it'll turn into something much uglier if extracted on a Windows or Linux machine due to the absence of bundles on those OSs.

It should be put into /Library/Application Support/Apple/Developer Tools/Project Templates/Application/Allegro Application/ instead of the current Project Builder template, i.e. you end up with just the files main.c and AllegroApp.xcodeproj in that folder.

I'd appreciate it if someone else could test this as I'm sure I'll have done something ridiculous like use absolute paths to places on my system.

Evert
Member #794
November 2000
avatar

Bump!
I can't test this myself, but I think someone else definately should.

X-G
Member #856
December 2000
avatar

Quote:

I expect it'll turn into something much uglier if extracted on a Windows or Linux machine due to the absence of bundles on those OSs.

Not that ugly, actually... just three files in a directory. Anyway, I can't test it either, not having a Mac, but here's another bump because someone should.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

GullRaDriel
Member #3,861
September 2003
avatar

I bump because I can not test it but wanna know the results of someone who will TEST IT !

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Trogdor
Member #8,184
January 2007

i run xcode 2.4.1 on a coreduo (intel) mac with allegro 4.2.1 freshly installed.
I removed the project template and dropped in your attached one, started xcode, created an allegro application, built it, and got a load of errors:

1Building target “test3” of project “test3” with configuration “Development” — (1 error, 5 warnings)
2 cd /Users/ellert/test3
3 /usr/bin/gcc-4.0 -o /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/test3 -L/Users/ellert/test3/build/Development -F/Users/ellert/test3/build/Development -filelist /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/test3.LinkFileList -framework Cocoa -framework Allegro -arch ppc -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
4/usr/bin/ld: warning -L: directory name (/Users/ellert/test3/build/Development) does not exist
5/usr/bin/ld: warning -F: directory name (/Users/ellert/test3/build/Development) does not exist
6/usr/bin/ld: warning /Library/Frameworks/Allegro.framework/Allegro cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded)
7/usr/bin/ld: warning /usr/local/lib/liballeg-main.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it)
8/usr/bin/ld: warning prebinding disabled because of undefined symbols
9/usr/bin/ld: Undefined symbols:
10_main
11__install_allegro_version_check
12_allegro_error
13_allegro_message
14_clear_to_color
15_font
16_install_keyboard
17_makecol
18_readkey
19_screen
20_set_gfx_mode
21_textout_centre_ex
22/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../crt1.o reference to undefined _main
23/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined __install_allegro_version_check
24/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _allegro_error
25/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _allegro_message
26/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _clear_to_color
27/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _font
28/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _install_keyboard
29/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _makecol
30/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _readkey
31/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _screen
32/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _set_gfx_mode
33/Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _textout_centre_ex
34collect2: ld returned 1 exit status
35 /usr/bin/ld: warning -L: directory name (/Users/ellert/test3/build/Development) does not exist
36 /usr/bin/ld: warning -F: directory name (/Users/ellert/test3/build/Development) does not exist
37 /usr/bin/ld: warning /Library/Frameworks/Allegro.framework/Allegro cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded)
38 /usr/bin/ld: warning /usr/local/lib/liballeg-main.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it)
39 /usr/bin/ld: warning prebinding disabled because of undefined symbols
40 /usr/bin/ld: Undefined symbols:
41 _main
42 __install_allegro_version_check
43 _allegro_error
44 _allegro_message
45 _clear_to_color
46 _font
47 _install_keyboard
48 _makecol
49 _readkey
50 _screen
51 _set_gfx_mode
52 _textout_centre_ex
53 /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../crt1.o reference to undefined _main
54 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined __install_allegro_version_check
55 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _allegro_error
56 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _allegro_message
57 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _clear_to_color
58 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _font
59 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _install_keyboard
60 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _makecol
61 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _readkey
62 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _screen
63 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _set_gfx_mode
64 /Users/ellert/test3/build/test3.build/Development/test3.build/Objects-normal/ppc/main.o reference to undefined _textout_centre_ex
65 collect2: ld returned 1 exit status
66Build failed (1 error, 5 warnings)

Thomas Harte
Member #33
April 2000
avatar

Quote:

/usr/bin/ld: warning /Library/Frameworks/Allegro.framework/Allegro cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded)
/usr/bin/ld: warning /usr/local/lib/liballeg-main.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it)
/usr/bin/ld: warning prebinding disabled because of undefined symbols
/usr/bin/ld: Undefined symbols:

Oh, it can only build Universal if you built the Allegro library in Universal form. It looks like on your computer Xcode can't find any PPC code in the Framework, so then has to generate errors when it wants to do the PPC linking.

If you're willing, what happens if you go right back to the start of Allegro install and do ./fix.sh macosx-universal rather than ./fix.sh macosx (and then the normal make & install steps subsequently, remembering to do sudo make install-framework EMBED=1)?

To be honest, I think Universal Binary libraries should be the default build option for Allegro, though I guess it isn't now because you'd have to check their availability first and that was perhaps too complicated a change to the make system?

While more knowledgable developers are looking — could anyone explain exactly why the UNIXy stuff is needed? I've asked before and received fairly decent answers but I'm still missing the final piece in the puzzle. I think it is something to do with properly branching into main? Is that so?

Matthew Leverton
Supreme Loser
January 1999
avatar

I imagine that it would do no good for me to test, considering I have a PPC macmini and Allegro's universal binary build won't work on it?

Trogdor
Member #8,184
January 2007

Hmm, interesting, aparently a rebuild of allegro with different flgs + the sudo make installs did not update anything.
I did sudo make uninstall , threw away the folder, unzipped anew and redid everything, this time with the macosx-universal flag to fix, and the embed=1 flag to install-framework.

After that the copy of your project template and the build again. It works!

The first time i got 6 warnings:

1Building target “test5” of project “test5” with configuration “Development” — (6 warnings)
2 cd /Users/ellert/test5
3 /usr/bin/gcc-4.0 -o /Users/ellert/test5/build/test5.build/Development/test5.build/Objects-normal/i386/test5 -L/Users/ellert/test5/build/Development -F/Users/ellert/test5/build/Development -filelist /Users/ellert/test5/build/test5.build/Development/test5.build/Objects-normal/i386/test5.LinkFileList -framework Cocoa -framework Allegro -arch i386 -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
4/usr/bin/ld: warning -L: directory name (/Users/ellert/test5/build/Development) does not exist
5/usr/bin/ld: warning -F: directory name (/Users/ellert/test5/build/Development) does not exist
6/usr/bin/ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4
7 /usr/bin/ld: warning -L: directory name (/Users/ellert/test5/build/Development) does not exist
8 /usr/bin/ld: warning -F: directory name (/Users/ellert/test5/build/Development) does not exist
9 /usr/bin/ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4
10 cd /Users/ellert/test5
11 /usr/bin/gcc-4.0 -o /Users/ellert/test5/build/test5.build/Development/test5.build/Objects-normal/ppc/test5 -L/Users/ellert/test5/build/Development -F/Users/ellert/test5/build/Development -filelist /Users/ellert/test5/build/test5.build/Development/test5.build/Objects-normal/ppc/test5.LinkFileList -framework Cocoa -framework Allegro -arch ppc -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
12/usr/bin/ld: warning -L: directory name (/Users/ellert/test5/build/Development) does not exist
13/usr/bin/ld: warning -F: directory name (/Users/ellert/test5/build/Development) does not exist
14/usr/bin/ld: warning prebinding disabled because dependent library: @executable_path/../Frameworks/Allegro.framework/Versions/4.2.1/Allegro is not prebound
15 /usr/bin/ld: warning -L: directory name (/Users/ellert/test5/build/Development) does not exist
16 /usr/bin/ld: warning -F: directory name (/Users/ellert/test5/build/Development) does not exist
17 /usr/bin/ld: warning prebinding disabled because dependent library: @executable_path/../Frameworks/Allegro.framework/Versions/4.2.1/Allegro is not prebound
18Build succeeded (6 warnings)

then i put it on deployment, built twice (changing some whitespace in between builds to force a rebuild)

2 warnings left:

Building target “test5” of project “test5” with configuration “Deployment” — (2 warnings)
      cd /Users/ellert/test5
    /usr/bin/gcc-4.0 -o /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/ppc/test5 -L/Users/ellert/test5/build/Deployment -F/Users/ellert/test5/build/Deployment -filelist /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/ppc/test5.LinkFileList -framework Cocoa -framework Allegro -arch ppc -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
/usr/bin/ld: warning prebinding disabled because dependent library: @executable_path/../Frameworks/Allegro.framework/Versions/4.2.1/Allegro is not prebound
    /usr/bin/ld: warning prebinding disabled because dependent library: @executable_path/../Frameworks/Allegro.framework/Versions/4.2.1/Allegro is not prebound
      cd /Users/ellert/test5
    /usr/bin/gcc-4.0 -o /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/i386/test5 -L/Users/ellert/test5/build/Deployment -F/Users/ellert/test5/build/Deployment -filelist /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/i386/test5.LinkFileList -framework Cocoa -framework Allegro -arch i386 -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
/usr/bin/ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4
    /usr/bin/ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4
Build succeeded (2 warnings)

The resulting app is 2.2 MB and includes the allegro framework and its .h files in the folder structure.

Not sure how i can check if it is indeed a universal binary though.

edit:
Found it, its just under the More Info button (duh)
Yes, it is an universal binary.

Thomas Harte
Member #33
April 2000
avatar

Quote:

I imagine that it would do no good for me to test, considering I have a PPC macmini and Allegro's universal binary build won't work on it?

I believe it should be possible to build Universal Binaries on any copy of OS X v10.4 as long as you have a recent Xcode. Apple seemed to announce that Xcode could build Universal Binaries a long time before the public release (as distinct from the one on the Intel transition developer kits) could. But maybe I'm wront about this.

In any case, I think we have a long time until anyone is thinking of a new Allegro release, so it's probably not worth worrying about especially if you're not a fan of the Mac environment.

Quote:

2 warnings left:

Oh, yeah, OS X v10.4 seems to be wacky about prebinding. Prebinding is deprecated in OS X v10.4 because "In Mac OS X 10.4, unprebound applications launch about as fast as prebound applications"(source). Since the framework Allegro builds is only suitable for the version of OS X you build on and later (i.e. at least 10.4 if you're building for a universal binary target) possibly some tool somewhere has automatically not prebound the Framework. As the Xcode project files can only be used in Xcode 2.x (and probably only 2.4+) they can therefore only be used on 10.4+ and so I should probably just disable prebinding in them!

Also possibly to fix: I haven't enabled ZeroLink for the Development build. I'm still not really sure what to do about that. ZeroLink is a good tool for development because it dramatically reduces build times while you're making small changes but, probably by design, it doesn't always correctly determine which source files are affected by header changes and you can get builds that crash just because you didn't do a clean before you make. It's notable that you can't enable ZeroLink for a Universal Binary build (i.e. Apple are saying "don't ship binaries built with ZeroLink"). I think the smart option is to leave it off.

Anyway, I'm babbling.

A new key question: can anyone confirm or contradict the behaviour seen by boulifb which means that even with the Framework embedded via this Xcode project the end user still needs /usr/local/lib/liballeg-4.2.dylib? I'm mindful that he never stated whether he'd done embed=1 at the correct moment and my guess is that if you don't specify embed then you get a Framework with a symbolic link to /usr/local/lib instead of a proper one.

I think I'm going to put together a "Framwork + XCode Project" binary distribution for OS X and see if I can get testers that way. In particular I notice that the only file that is used in /usr/local/lib with this project is liballeg-main.a, so it would probably be acceptable to just incorporate that into the project template.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

I believe it should be possible to build Universal Binaries on any copy of OS X v10.4 as long as you have a recent Xcode. Apple seemed to announce that Xcode could build Universal Binaries a long time before the public release (as distinct from the one on the Intel transition developer kits) could. But maybe I'm wront about this.

In any case, I think we have a long time until anyone is thinking of a new Allegro release, so it's probably not worth worrying about especially if you're not a fan of the Mac environment.

It probably should be possible, but the latest Xcode on the latest 10.4 on PPC currently produces this error when building the universal version of Allegro:

http://www.allegro.cc/forums/thread/589202

Trogdor
Member #8,184
January 2007

Could i test that by deinstalling allegro and running the test project i built ?

Thomas Harte
Member #33
April 2000
avatar

Quote:

It probably should be possible, but the latest Xcode on the latest 10.4 on PPC currently produces this error when building the universal version of Allegro:
http://www.allegro.cc/forums/thread/589202

Well that's peculiar! And one more argument for a binary distribution, I guess.

EDIT

Quote:

Could i test that by deinstalling allegro and running the test project i built ?

Yep. Just moving /usr/local/lib should test the problem boulifb had. You'll probably need administrator privileges to do it though. To get to the right place in the Finder (which normally treats /usr and so on as invisible) just open a Finder window and select Go->Go to Folder... from the menubar (or press command+shift+g) and type /usr/local into the little dialogue that appears. Finder will limit your actions because you're not the owner, but if you try and send it to the Trash it'll give you the usual Authentication prompt for the administrator password (and username if it isn't you) and you can just temporarily keep it in the Trash.

I don't think the UNIX system is clever enough to still be able to find files even after you've renamed them or moved them (like all the native programs can) so even without knowing whether files can be read from the Trash (which I doubt) that should be a sufficient test.

And my machine passes it, by the way.

Trogdor
Member #8,184
January 2007

i archived the 2 libraries, threw them away and emptied my trash.
The compiled test works fine.
Compiling it again in xcode gives the expected:

Building target “test5” of project “test5” with configuration “Deployment” — (1 error)
      cd /Users/ellert/test5
    /usr/bin/gcc-4.0 -o /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/ppc/test5 -L/Users/ellert/test5/build/Deployment -F/Users/ellert/test5/build/Deployment -filelist /Users/ellert/test5/build/test5.build/Deployment/test5.build/Objects-normal/ppc/test5.LinkFileList -framework Cocoa -framework Allegro -arch ppc -prebind -Wl,-Y,1455 -L/usr/local/lib -lalleg-main
/usr/bin/ld: can't locate file for: -lalleg-main
collect2: ld returned 1 exit status
    /usr/bin/ld: can't locate file for: -lalleg-main
    collect2: ld returned 1 exit status
Build failed (1 error)

so the library is realy gone.
I can not test it on another mac.

Thomas Harte
Member #33
April 2000
avatar

Okay, here it is: my first bash at a binary distribution of Allegro for OS X. The zipfile should include a Universal Framework, Xcode project and installation instructions. I'm going to go and try it on my own PowerPC now, I'd be grateful if others could give it a whirl. It'd be good if we can get this to work properly, as a lot of Allegro people seem to be moving to OS X right now and many of them probably don't know or don't want to know how to use the UNIX underneath.

I've enabled ZeroLink, since Xcode does by default for all development builds. I've also put the two build directories into the template so that you don't get any warnings on your first build.

EDIT: similar issues to the ones Bob describes trying to build a Universal Binary of the framework on a PPC machine show themselves when trying to build a Universal Binary with my template. After disabling the Intel target from Xcode though, it is perfectly possible to build a PowerPC binary. I'll hit some Mac-specific forums and see what I can learn.

EDIT2: and I'll fix the obvious mistake (or inconsistency if you prefer) in the way paths are identified in the installation instructions...

EDIT3: All fixed. New suggested distribution attached. So far tested successfully by me on a 2.16 Ghz Core Duo MacBook Pro and a 667 Mhz G4 PowerBook. Both happily produced universal binaries that seemed to have the Allegro framework correctly embedded. Please test!

Matthew Leverton
Supreme Loser
January 1999
avatar

Attached is the default file built using OSX 10.4.8 / XCode 2.4.1 on my PPC Macmini. It appeared to be a successful universal build. Does this mean (judging by edit #1 and #3) you've solved the issues that came up in the thread I linked?

I was set up for gcc 3.3, which failed. I used gcc_select to go to 4.0 and then it worked. Is 4.0 required for Universal builds? I'm wondering because I always used 3.3 with Allegro to get maximum backward support (there's probably other ways, but that worked easily enough). Do you know what version of OS X is required to run something built using your binary distribution?

The other question I have is, would it be possible to get a UNIXy version included as well? I often want to use it (allegro-config) on the command line to build a 3rd party cross platform Allegro application using the project's makefile.

Thomas Harte
Member #33
April 2000
avatar

Quote:

Does this mean (judging by edit #1 and #3) you've solved the issues that came up in the thread I linked?

Only in Xcode. I haven't figured out the commandline fix yet. The problem is, I think, that Allegro uses the default SDK target. On Intel the default target is a Universal version of the 10.4 SDK. On PowerPC it seems to be a PowerPC version. The answer, I've discovered vaguely is to set

SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

which I think are environment settings...

Since the Universal Framework version builds fine with the libraries supplied with the Intel version of the OS and programs built with that Framework work fine on PPC, I haven't really focussed on the problem.

Quote:

I was set up for gcc 3.3, which failed. I used gcc_select to go to 4.0 and then it worked. Is 4.0 required for Universal builds?

4.0 seems to be required for the Intel half at least.

Quote:

I'm wondering because I always used 3.3 with Allegro to get maximum backward support (there's probably other ways, but that worked easily enough). Do you know what version of OS X is required to run something built using your binary distribution?

Definitely 10.4 at the minute. I'm still reading up on the topic. It seems that it should be easy enough to change my Xcode project slightly so that it builds the Intel half with GCC 4.0 and the 10.4 SDK and, in that example, the PowerPC half with GCC 3.3 and the 10.3 SDK. My guess is that it'll work just fine with the 10.2 SDK too. But then we're possibly wading into support trouble because at least the 10.2 SDK and maybe 10.3 too are not parts of the default Xcode install.

I'll try to look into that properly this weekend (I'm busy tomorrow). I'll need to figure out some way to get the Allegro Framework built similarly, which won't be easy for me as I'm a makefile thickie. I'll at least try and make a comprehensive list of the compiler flags that need to be passed down the food chain so that someone better at this stuff can hopefully help.

But in summary: it should be possible to get a project put together that builds Allegro code for all Macs that run 10.2+, regardless of processor. However the current one doesn't.

I should say that for most of next week I'm away from home and while I'll have net access and I'll have my Mac, my Mac probably won't have net access. So I can't promise rapid progress.

Quote:

The other question I have is, would it be possible to get a UNIXy version included as well? I often want to use it (allegro-config) on the command line to build a 3rd party cross platform Allegro application using the project's makefile.

My feeling is that UNIXy versions should be put in a separate zip. I have two arguments.

I think it would be better not to treat Xcode and the commandline tools as a single environment because it is easier for new users who will tend to start with Xcode and probably only venture onto the commandline later. A binary pack purely for the Xcode IDE can be installed entirely from the Finder by dragging and dropping, whereas a UNIXy install is more complicated.

For a UNIXy install You have to copy a bunch of files into /usr/local which can't be seen from the Finder without using the "Go To Folder..." command which is not something people normally encounter and many probably aren't even aware it's there You also have to deal with Finder's oddities concerning directories you don't have write privileges to and then drop to the shell anyway to play around with your PATH.

I also think it would be better not to treat Xcode and the commandline tools as a single environment because it doesn't make things much harder for experienced users. Downloading two zips and redistributing the relevant files out of each is not substantially harder than redistributing the files from one zip for anybody that knows how to use the commandline.

Matthew Leverton
Supreme Loser
January 1999
avatar

I don't necessarily disagree with your arguments, but Peter Hull had put together a similar binary package that (I believe) installed both. It was an installer that you just clicked through. So while I think it would be nice to be able to do that, I do agree that the more pressing need is simply for an OS X friendly XCode environment.

Quote:

The answer, I've discovered vaguely is to set

SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

which I think are environment settings...

I tried setting those, but to no avail. I think perhaps they are only for XCode. I couldn't find any reference to anyone setting them as environment variables.

Edit:

Adding this to the CFLAGS, LFLAGS, and DYLINK_FLAGS fixes it: -isysroot /Developer/SDKs/MacOSX10.4u.sdk

Patch for the makefile attached.

Thomas Harte
Member #33
April 2000
avatar

Quote:

Peter Hull had put together a similar binary package that (I believe) installed both. It was an installer that you just clicked through.

It would have been nice if he'd told somebody about it!

Matthew Leverton
Supreme Loser
January 1999
avatar

This is the most recent mention of it that I can find:

http://www.allegro.cc/forums/thread/523945/524307#target

I've relinked the file here. I don't really remember exactly what it included, so it may not even be helpful to you.

Thomas Harte
Member #33
April 2000
avatar

Quote:

I don't really remember exactly what it included, so it may not even be helpful to you.

libtool (I think - but I might have my tool names confused) allows you to do things like strip or add the code for one processor family from a library, so if Peter is still using 10.2 perhaps the ultimate insurance way to ensure that any potential binary Framework distribution is back compatible that far is just to make it that way rather than playing about with compiler flags ad infinitum. I'll make sure that's a real option and not one I made up in my head and then PM him...

I might try and get hold of a copy of 10.2 or 10.3 to put on my old PowerPC machine too. For boring reasons I have 10.0 and 10.1 but not 10.2 (having lost the machine's original stall discs) or 10.3 (having never owned install discs).

EDIT:

Quote:

Source
Select a Deployment OS

To set the deployment target in a makefile, use another makefile variable of the form:

ENVP= MACOSX_DEPLOYMENT_TARGET=10.3

The value you specify for MACOSX_DEPLOYMENT_TARGET determines the minimum target system for your software. In the preceding example, the target system is 10.3 . To use this variable in your makefile, include it in front of your compile and link commands. For example, a simple C program might use the following build commands:

testapp: main.o

${ENVP} ${CC} ${LDFLAGS} -o testapp main.o

main.o:

${ENVP} ${CC} ${CFLAGS} -c main.c -o main.o

I think if you changed the Apple example to instead do:

ENVP= MACOSX_DEPLOYMENT_TARGET_i386=10.4 MACOSX_DEPLOYMENT_TARGET_ppc=10.2 GCC_VERSION_ppc=3.3 GCC_VERSION_i386=4.0 SDKROOT_ppc=/Developer/SDKs/MacOSX10.2.8.sdk SDKROOT_ppc=/Developer/SDKs/MacOSX10.4u.sdk
Then, provided you had the 10.2.8 SDK installed (it's provided with Xcode, but isn't a default install) you'd get a PowerPC binary built for 10.2.8 with GCC 3.3 bonded to an Intel binary built for 10.4u with GCC 4.0.

Extrapolating from the way these settings override the main target setting in Xcode, but Apple still seem to want you to set it to 10.4u, I think the existing -isysroot CFLAGS fix should be kept concurrently.

Now how would I persuade the Allegro makefiles to do that? They're too convoluted for me, given that I otherwise have approximately 0% makefile experience.

boulifb
Member #7,909
October 2006

ok, works fine on my mac.
Thomas: you were right, I forgot to use the EMBED flag to 1 when installing the framework.

Now, when making UBs it works well on intel and PPC macs :)

Fred.

Thomas Harte
Member #33
April 2000
avatar

That's good. In that case I think the Xcode project is finished. The one I have on my machine is altered slightly to build against the 10.2.8 SDK for PowerPC and the 10.4u SDK for Intel, but I'm not sure how the developers would feel about that given that the 10.2.8 SDK is only an optional install. It'd probably be better to do some ./fix.sh magic and select an Xcode project based on the available SDKs but that's completely out of the limited range of my skills.

It also won't be worth doing if I can't figure out an answer to the question I posed as an EDIT in my previous post...

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

Now how would I persuade the Allegro makefiles to do that? They're too convoluted for me, given that I otherwise have approximately 0% makefile experience.

I'll see if it works for me.

Update:

The only setting that did anything was MACOSX_DEPLOYMENT_TARGET. The ones you thought might work did nothing, as far as I can tell. I don't have any 10.2 or 10.3 system to test on, so I just used otool to inspect the file.

I created a minimal "Hello World" program. I then ran otool -L to see what they linked against. These are the results:

testapp-10.3: Mach-O fat file with 2 architectures
testapp-10.3 (for architecture ppc):    Mach-O executable ppc
testapp-10.3 (for architecture i386):   Mach-O executable i386
testapp-10.4: Mach-O fat file with 2 architectures
testapp-10.4 (for architecture ppc):    Mach-O executable ppc
testapp-10.4 (for architecture i386):   Mach-O executable i386

testapp-10.3:
        /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)
testapp-10.4:
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)

Whether or not that means it works, I don't know. But they are different. If I supply no explicit settings, I (as expected) get a file that looks like the testapp-10.4.

The makefile wouldn't have to even be modified, because this works as well:

export MACOSX_DEPLOYMENT_TARGET=10.3
gcc -O2 -s -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ -c main.c -o main.o
gcc -O2 -s -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk/ -o testapp main.o

So I cannot say conclusively that the above creates a file that works on 10.3, it does do something... I'm downloading the 10.2 SDK, and I'll see what results I get with that.

Update 2: Attached are three static linked Allegro "Hello World" OS X applications that supposedly target 10.2, 10.3, and 10.4.

Thomas Harte
Member #33
April 2000
avatar

Quote:

The ones you thought might work did nothing, as far as I can tell.

The only definite way I found to test my Xcode project was to try to use system calls that aren't available in 10.2 or 10.3 and wait for the expected build errors. In particular, the (Objective-C) NSAlert class only appears in 10.3+ and the NSAlert method alertWithError: only exists in 10.4+.

Anyway, I'm back with my Mac tonight so I'll have a go at putting together a binary installer for 10.2 -> 10.4 targetting libraries, frameworks & Xcode projects. Hopefully whoever is in charge of maintaining the build system has noticed this thread?

Matthew Leverton
Supreme Loser
January 1999
avatar

I created the following test:

#import <stdio.h>
#import <AppKit/NSAlert.h>

int main( int argc, const char *argv[] ) {
    NSAlert *alert = [[[NSAlert alloc] init] autorelease];

    printf( "hello world\n" );
    return 0;
}

It would not compile with this:

MACOSX_DEPLOYMENT_TARGET=10.2 g++ -O2 -s -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.2.8.sdk -c main.mm -o main.o

But it would compile with this:

MACOSX_DEPLOYMENT_TARGET=10.2 g++ -O2 -s -arch ppc -arch i386 -isysroot Developer/SDKs/MacOSX10.4u.sdk -c main.mm -o main.o

Therefore obviously the MACOSX_DEPLOYMENT_TARGET doesn't actually override the SDK specified, as the Apple article implies. It does do something as evident by my previous post, but it definitely is not forcing the given target.

Right now, it's looking like the only guaranteed way to make it work within the makefile is to change the OS X build process to use osx_i386 and osx_ppc folders. Build Allegro once for each target and then use lipo to put them back together.

 1   2 


Go to: