PDA

View Full Version : Linking Issues on MacOS X 10.6.5



Mario Donick
05-01-2011, 12:22 PM
To compile my game on MacOS, I use the following command:

fpc -Mobjfpc -ve -k-framework -kSDL -k-framework -kSDL_image -k-framework -kCocoa fprl.pp

Everything goes fine, until the linker tries to link X11 libs:

Linking fprl
ld: library not found for -lX11


What do I have to do (or install, or change) in order to make this work?

Mario Donick
05-01-2011, 04:03 PM
Okay, now I'm trying

fpc -Mobjfpc -ve -k-framework -kSDL -k-framework -kSDL_image -k-framework -kCocoa -Fl/usr/X11/lib fprl.pp

and I get the successful

Linking fprl
11378 lines compiled, 1.2 sec

However, the created binary does not work at all. While on Windows and on Linux everything goes well (my SDL window appears), on MacOS I only get a massive amount of errors, which can be traced back to the point where SDL wants to set its video mode. The call stack is:



0 CoreFoundation 0x994ad6ba __raiseError + 410
1 libobjc.A.dylib 0x997fb509 objc_exception_throw + 56
2 CoreFoundation 0x994ad3e8 +[NSException raise:format:arguments:] + 136
3 CoreFoundation 0x994ad35a +[NSException raise:format:] + 58
4 AppKit 0x9524a9be _NSCreateWindowWithOpaqueShape2 + 519
5 AppKit 0x951cf8a6 -[NSWindow _commonAwake] + 1624
6 AppKit 0x951cc56e -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1524
7 AppKit 0x951cb1c1 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1568
8 AppKit 0x951cab9b -[NSWindow initWithContentRect:styleMask:backing:defer:] + 71
9 SDL 0x00b2467f SDL_SoftStretch + 27215
10 SDL 0x00b235f8 SDL_SoftStretch + 22984
11 SDL 0x00b1714f SDL_SetVideoMode + 623


Anybody seen something like this with SDL on MacOS? Both Frameworks are installed correctly in /lib/Framework .

Mario Donick
05-01-2011, 04:11 PM
Okay, sorry for spamming, but after I deleted the sdl.pp and sdl_image.pp that have been in the source directory of my game (so that fpc used the same files as provided by fpc itself), the SDL mode of my game works. :-D You can't imagine how happy I am now. Since July 2010 I'm trying this, and finally it worked. :D

But now I've got a different problem, which is concerning 1024x768 output on MacOS (800x600 window is working, but not 1024x768) -- but for this, I will open a new thread.

Mario Donick
06-01-2011, 12:21 PM
... because I accidently removed all the contents of my /usr/local folder, I had to reinstall fpc, lazarus and SDL. Because the framework version did not work anymore when I tried to use the compiler call above (it did not find the SDL library although libSDLmain.a was again in /usr/local/lib), I removed the SDL framework and instead installed the source version of SDL. ./configure, make, make install worked without problems and now all SDL libs are in /usr/local/lib again. Only for SDL image, I still use the framework version.

I changed the compiler call to

fpc -Mobjfpc -ve -k-lSDL -k-lSDLmain -k-framework -kSDL_image -k-framework -kCocoa -Fl/usr/X11/lib fprl.pp


This gives me the following output:

Linking fprl
ld: warning: in /usr/local/lib//libSDL.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib//libSDLmain.a, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib//libSDL-1.2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
"_main", referenced from:
__start in crt1.o
(maybe you meant: _SDL_main)
"_SDL_SaveBMP_RW", referenced from:
_SDL_SDL_SAVEBMP$PSDL_SURFACE$PCHAR$$LONGINT in sdl.o
"_SDL_SetVideoMode", referenced from:
_P$FPRL_SETOPTIONS in fprl.o

and so on.

Esp. the first three lines are disturbing me.

What can I do now? I was so happy that everything worked, but obviously I did not understand how I got SDL to work on my system, so I can't explain the process to end users of the game as well.

Please please help ... (I read all the topics related to SDL on MacOS in this forum, I also read the section on freepascal.org).


Edit: Just in case it is a problem with PowerPC vs. i386, I tried to use the option to build a universal binary, as stated in the MacOS X readme in the SDL source folder. There it says I could call a script named fatbuild.sh. Well, I tried, but this script seems to have errors, or not to work anymore on Leopard.

Mario Donick
06-01-2011, 05:33 PM
Again -- I removed FPC, Lazarus, everything SDL related. What I then did was to set up everything, so the following conditions are given:

1. MacOS "Snow Leopard" 10.6.5
2. All developer Tools installed

3. FPC 2.4.2, installed in /usr/local/*
4. SDL.Framework 1.2.14, installed in /Library/Frameworks
5. SDL_Image.Framework, installed in /Library/Frameworks

6. Compiled libSDLMain.a, based on SDL devel-lite 1.2.14, installed in /usr/local/lib and in the source dir of my program

7. Using the SDL units provided by FPC 2.4.2

8. Compiler call: fpc -Mobjfpc -ve -k-framework -kSDL -k-framework -kSDL_image -k-framework -kCocoa -Fl/usr/X11/lib -Fl/usr/local/lib fprl.pp

(it does, by the way, makes no difference if I explicitly refer to libSDLMain.a by adding -lSDLMain to the compiler options.)

So, why do I still get the "library not found for -lSDL-1.2.0" message? I simply don't understand what's going wrong here ...

WILL
06-01-2011, 10:03 PM
Sorry that this may seem like a one-way conversation for you so far. I myself am a new Mac user and I love FPC and have been using Lazarus and SDL for my development for some time so I find this topic very interesting actually. However I unfortunately cannot offer you too many solutions as I find myself stuck with the current version of Lazarus' use of the debugger crashing on my system.

I am however aware of the problem surrounding the current JEDI-SDL version with Lazarus on Mac OS X. Fortunately I just so happen to have direct access of the maintainer of the library and he has given me an unofficial copy of it, updated to work properly for the Mac. If you are interested, I can email you a copy of it to test out, just PM me and we'll talk.

I'm glad that there are more people trying to develop with Object Pascal on the Mac and posting about it. I myself am finding resources on the platform a bit sparse at the moment so the more people posting about this the better. Thanks for doing your part! :)

code_glitch
07-01-2011, 12:26 AM
Mac os is a little like linux isnt it? Maybe my post here may be of some use to you: http://www.pascalgamedevelopment.com/showthread.php?6265-Ubuntu-amp-FPC-Confused&highlight=ubuntu

i'm not sure if this helped beyond a hint, but stil...

Mario Donick
07-01-2011, 08:47 AM
Thanks for the supporting posts. At least I know now that I'm not spamming ;)

Perhaps, if we figured out how to set up a working SDL + FPC environment on MacOS in a way which works on all recent Macs, we could write an article about it.

Additionally, it may be important to summarize how to distribute a developed game to the end users -- because I fear that simply installing SDL Frameworks on the end user machine may not be enough (here I would need information, too, but later, when I again successfully linked my game...)

@code_glitch: Well, I wish it was as easy as with Linux. On Mac, first of all you have to decide if you want to use the standard Unix/Linux way of having the SDL libraries in a standard directory like /usr/local/lib, OR if you want to have the Mac way of having the SDL libraries as a Framework in /Library/Frameworks . Getting everything to work on Linux was very easy, I simply installed SDL, SDL_image and the related development packages, and simply could call fpc fprl.pp, without any special parameters. On Mac OS, as shown in the previous posts, its all a mess, and nothing works currently, regardless if I use the Unix/Linux way or the Mac way.

@WILL: PM.

JSoftware
07-01-2011, 01:31 PM
Try seeing this page

http://wiki.freepascal.org/FPC_and_SDL#Mac_OS_X_specific_issues

Mario Donick
07-01-2011, 02:07 PM
Thanks, JSoftware, but I know this page. The setup described above was done after reading that page ...

JSoftware
07-01-2011, 04:43 PM
sdl.pas says it does this:


SDLLibName = 'libSDL-1.2.0.dylib';
{$linklib libSDL-1.2.0}
{$linklib SDLmain}
{$linkframework Cocoa}
{$PASCALMAINNAME SDL_main}

I don't know enough about the framework/library business to say what that means. Atleast it'll try to link to libSDL-1.2.0. Try to see if you can find some libSDL-x file somewhere and see if it uses some other version number. 1.2.0 should be the major revision number they use, but I could be wrong

Mario Donick
07-01-2011, 05:50 PM
This was an interesting remark. The folder SDL.framework contains one 1,4 MB sized binary file, simply called SDL. Nowhere on my system is a file or a symlink called libSDL-1.2.0.dylib .

Creating a symlink with that name improves nothing.

JSoftware
07-01-2011, 05:53 PM
Is there a libSDL-*.dylib?

code_glitch
07-01-2011, 06:44 PM
dylib?? Is that like a SO file? If it is, I doubt it would be in the framework folder - they arent on linux anyway... Arent all those so / dylibs in really obscure places usually?

EDIT:
Ps. I see that macs still use 1.44mb floppies:


one 1,4 MB sized binary file


Need a cd drive? I have one. - a take on some person bringing a mac for ballmer to sign ;)

Sorry - couldn't help it. I'm not a mac fan - but neither am I windows. Unfortunately I don't have a choice in the latter most of the time.

Mario Donick
07-01-2011, 09:46 PM
Yes I think dylib files would be so files on Linux.

No, I don't have any SDL related dylibs on my system.

According to the availabe documentation, copying the SDL Framework folders into /Library/Frameworks should be enough to install SDL. But obviously it isn't. Argh!!!

code_glitch
07-01-2011, 10:32 PM
http://www.pascalgamedevelopment.com/images/icons/icon8.png

Ah yesw, I have a bad habit of that... sorry.

If its the runtime - try putting those dynalib thingys in the same folder as the executeable or somehwere the system can find them. I would guess that the problem here is you need some type compiling libs? Perhaps try http://sourceforge.net/projects/jedi-sdl/ since in my windows expereince these worked a treat. My mac user-time extands to a comprehensive 7 hours so I'm far from expert (that one button mouse gets to me. I rightclick once every 10 seconds by habit to do everything, and on mac I click everything I shouldn't. Thank god it doesnt crash at the first glimpse of trouble s) )

Anyway, dont forget that you may need the LibSdl AND the libsdl-DEV for thins t work, as I found out. Beyond that is unkown for me so this will most likely be my last post on this topic.

Mac users: I am very sorry to have offended you in any way. I totally admit that MacWorld and Steve Jobs makes for a much saner atmosphere at product launches than M$. Also - please understand: not everyone is blessed with error-free computing like you and that not all devices are made by apple. so they break. and when things break we get dpressed. so we make jokes ;)

Edit: and oh, this is my 250th post? whaaaat? that many alreadyy?

Mario Donick
08-01-2011, 10:20 AM
No, the angry smiley was not directed at you! It was directed at MacOS ...

Since several versions, the JEDI SDL libs are not needed anymore, they are included in FPC, and it is SAID that these units care themselves about the correct libraries.

It all works different on MacOS than on Linux or Windows, regardless of MacOS having a Unix core ...

code_glitch
08-01-2011, 10:40 AM
Ah, now - wait wwwhaaaat? So is the problem compiling, or running sdl programs? I am totally lost.

Mario Donick
08-01-2011, 11:08 AM
The problem is compiling SDL programs, for now. I did this once, some days ago (http://lambdarogue.net/dl-showentry.php?n=194), but then stupidly lost my whole setup and now don't remember how it was.

I then had several attempts, all with the SDL units provided by FPC (the JEDI-SDL units which I use on Windows and Linux never gave me any positive results on Mac), plus the SDLmain library which is found in the "devel-lite" folder of the SDL Mac Download. This "SDLmain" is required for developing, too.

1) The Frameworks only. The Frameworks are, I think, always needed on Mac, because in these are both the runtime and the development headers.

2) Frameworks + the classic Unix/Linux way: I compiled SDL from source, which lead to several libs with correct names in /usr/local/lib. The compiler found the libs, but they somehow did not contain the correct functions expected by the SDL units, and FPC complained about it.

3) Ports: Ports are similar to a package manager on Linux, but usually install everything in /opt/var/... This gave me the same negative result as 2)


According to the FreePascal wiki, with FPC 2.2.2 and 2.4.2, the 1st variant should be sufficient. But somehow ...

code_glitch
08-01-2011, 11:14 AM
I hear that apt-get also works on mac. Would that mean that you could use t commands I did on ubuntu? I know a lot of mac users dont like it - but it might work as a last resort:

http://techline4teens.com/archives/81

seems to make a decent summary. I wonder if tHat would work? althoughbyou may need to use it to install all the apps you need for development. Just abother thought.

Mario Donick
08-01-2011, 11:21 AM
Yep. This is the 2nd variant I mentioned (ports). Fink is another approach (but currently not working on Snow Leopard). Both work like apt-get. Hmmm... perhaps they also have a FreePascal port ... if this would be the case, I could use the Ports or Fink version of SDL and FPC.

If that worked, I only fear that the end users would need to install Ports, too ... or at least X11. I don't know if the casual Mac user, who would perhaps play my roguelike game, would do this.

However, I'll check this idea out.


Edit: Ok, there's no Ports version of FPC *sigh*

JSoftware
08-01-2011, 11:34 AM
Some sdl wiki page mentioned that you needed to use Projectbuilder to build sdl properly(as frameworks). Did you do that?

And when you used frameworks+the unix way what was the problem then, precisely?

Mario Donick
08-01-2011, 12:25 PM
No -- I simply did ./configure, make, make install, as mentioned in the MacOS readme of the SDL source. Also the FPC wiki says that you don't need to use the Framework, you CAN use the Unix way.

The generated libraries were stored in the right place, with the right names, but the linker complained that they were built for a wrong platform (although I explicitly told the configure script to build for i386 Intel Macs, not for PowerPC Macs).

JSoftware
08-01-2011, 12:51 PM
And are you on an i386 or a x86_64?

Mario Donick
08-01-2011, 07:51 PM
The Mac Mini has an Intel Core Duo 2 (= i386).

At the moment, I'm considering simply wrapping the Windows version of the game with WineBottler to produce the Mac version. I tried this, this works, but a whole Wine environment would be included then. Not the best way.

JSoftware
08-01-2011, 07:57 PM
Core Duo 2 can run both i386 and x86_64. I thought OSX usually ran as x86_64?

Try to compile your program as fpc -Px86_64 fprl

Edit: Nevermind that. I was wrong...

Mario Donick
08-01-2011, 09:48 PM
Never mind. I appreciate all guesses :)

I have again played around with bundling the game plus Wine. It looks good. One single .app that can safely reside in MacOS' app folder. It's as fast as on Windows, everything works very good (okay, that's because its a simple 2D game which is handled well by Wine).

However, its size is around 420 MB, and from this, the game is only 200 MB. I'll see if I can host this somewhere.

Stoney
08-01-2011, 10:42 PM
Also the FPC wiki says that you don't need to use the Framework, you CAN use the Unix way.


This is not recommended. The end-user would need to install libSDL*.dylib and all SDL friends on their computer. The framework way is much better for deployment.

I wouldn't bundle it with WineBottler, native applications are always faster than applications running through Wine.

If you use "fpc -Mobjfpc -ve -k-lSDLmain -k-framework -kSDL -k-framework -kSDL_image -k-framework -kCocoa -Fl/usr/X11/lib fprl.pp" and the JEDI-SDL headers everything should work fine.

Alternatively, you can add


{$IFDEF DARWIN}
{$PASCALMAINNAME SDL_main} // Needed for Snow Leopard
{$linklib SDLmain}

{$linkframework Cocoa}
{$linkframework SDL}
{$linkframework OpenGL}

{$linkframework SDL_image}
{$linkframework SDL_mixer} // If you are using SDL_mixer
{$IFDEF USE_SDL_GFX} // If you are using SDL_gfx
{$linkframework SDL_net} // If you are using SDL_net
{$ENDIF}

at the top of your main source file and compile your application with: fpc -Mobjfpc -ve -Fl/usr/X11/lib fprl.pp

Btw: If you are still interested in Universal binaries, this is my Mac and Linux compile script which compiles an universal binary, copies all my assets and creates a nice .app file around the application. I've been using this in all my Mac FreePascal SDL game projects.


#!/bin/sh

FPC_BIN=`which fpc`
BIN_FOLDER="../bin"
SRC_MAIN="main.lpr"
LIB_FOLDER="../lib"
EXEC_NAME="execname"
APP_NAME="My Application Name"


cd ../source
if [ -f /System/Library/Frameworks/Cocoa.framework/Cocoa ]
then

FPC_BIN=`which ppc386`

# Compiling Intel binary
${FPC_BIN} @config.cfg -k-L/usr/X11R6/lib ${SRC_MAIN}
mv ${BIN_FOLDER}/main ${BIN_FOLDER}/main-intel
rm ${BIN_FOLDER}/link.res
rm ${BIN_FOLDER}/*.o ${BIN_FOLDER}/*.ppu
rm ${SRC_HEADER}/*.o ${SRC_HEADER}/*.ppu ${SRC_HEADER}/*.dcu ${SRC_HEADER}/*.a


FPC_BIN=`which ppcppc`

# Compiling PowerPC binary
${FPC_BIN} @config.cfg -k"-L${LIB_FOLDER}/frameworks -L/usr/X11R6/lib" ${SRC_MAIN} -XR/Developer/SDKs/MacOSX10.5.sdk/ -k-macosx_version_min -k10.5
mv ${BIN_FOLDER}/main ${BIN_FOLDER}/main-ppc
rm ${BIN_FOLDER}/*.o ${BIN_FOLDER}/*.ppu


# Creating universal binary
if [ -f ${BIN_FOLDER}/main-intel ] && [ -f ${BIN_FOLDER}/main-ppc ]
then
strip ${BIN_FOLDER}/main-intel
strip ${BIN_FOLDER}/main-ppc

lipo -create ${BIN_FOLDER}/main-intel ${BIN_FOLDER}/main-ppc -output ${BIN_FOLDER}/${EXEC_NAME}
rm -rf ${BIN_FOLDER}/main-intel
rm -rf ${BIN_FOLDER}/main-ppc
fi

if [ -d "${BIN_FOLDER}/${APP_NAME}.app" ]
then
echo " ... Removing old application"
rm -rf "${BIN_FOLDER}/${APP_NAME}.app"
fi

echo " ... Creating Application Bundle"

mkdir "${BIN_FOLDER}/${APP_NAME}.app"
mkdir "${BIN_FOLDER}/${APP_NAME}.app/Contents"
mkdir "${BIN_FOLDER}/${APP_NAME}.app/Contents/MacOS"
mkdir "${BIN_FOLDER}/${APP_NAME}.app/Contents/Resources"
mkdir "${BIN_FOLDER}/${APP_NAME}.app/Contents/Frameworks"

cp -R ../resources/ "${BIN_FOLDER}/${APP_NAME}.app/Contents/Resources/"

# Copy frameworks from System
cp -R /Library/Frameworks/SDL.framework "${BIN_FOLDER}/${APP_NAME}.app/Contents/Frameworks/"
cp -R /Library/Frameworks/SDL_mixer.framework "${BIN_FOLDER}/${APP_NAME}.app/Contents/Frameworks/"
cp -R /Library/Frameworks/SDL_ttf.framework "${BIN_FOLDER}/${APP_NAME}.app/Contents/Frameworks/"

mv "${BIN_FOLDER}/${EXEC_NAME}" "${BIN_FOLDER}/${APP_NAME}.app/Contents/MacOS/"

echo "<?xml version='1.0' encoding='UTF-8'?>\
<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">\
<plist version=\"1.0\">\
<dict>\
<key>CFBundleDevelopmentRegion</key>\
<string>English</string>\
<key>CFBundleExecutable</key>\
<string>${EXEC_NAME}</string>\
<key>CFBundleIconFile</key>\
<string>logo.icns</string>\
<key>CFBundleIdentifier</key>\
<string>com.freezedev</string>\
<key>CFBundleInfoDictionaryVersion</key>\
<string>6.0</string>\
<key>CFBundleName</key>\
<string>${APP_NAME}</string>\
<key>CFBundlePackageType</key>\
<string>APPL</string>\
<key>CFBundleSignature</key>\
<string>PSGR</string>\
<key>CFBundleVersion</key>\
<string>1.0</string>\
<key>CSResourcesFileMapped</key>\
<true/>\
</dict>\
</plist>" >> "${BIN_FOLDER}/${APP_NAME}.app/Contents/Info.plist"

echo "APPLFDRS" >> "${BIN_FOLDER}/${APP_NAME}.app/Contents/PkgInfo"

else
if [ -f /usr/lib64 ]
then
${FPC_BIN} @config.cfg ${SRC_MAIN}
rm ${BIN_FOLDER}/*.o ${BIN_FOLDER}/*.ppu
else
${FPC_BIN} @config.cfg ${SRC_MAIN}
rm ${BIN_FOLDER}/*.o ${BIN_FOLDER}/*.ppu
fi

if [ -f "${BIN_FOLDER}/main" ]
then
mv "${BIN_FOLDER}/main" "${BIN_FOLDER}/${EXEC_NAME}"
fi
fi


If you want to use this for your projects, you need to change the variables at the top (BIN_FOLDER, SRC_MAIN, LIB_FOLDER, EXEC_NAME and APP_NAME) to the value you want them to be. You need to delete the reference to config.cfg if you are not using a config file for your project and libSDLmain.a should be in LIB_FOLDER/frameworks for PowerPC compilation.

code_glitch
08-01-2011, 10:55 PM
oooh, shiny. i must say; i do appreciate bash scripts a lot. now where can i use this seeing i dont have mac? hmm. tough one ;)

Mario Donick
09-01-2011, 08:35 AM
@Stoney, thank you! This looks like a great solution, I'll try this now and report back soon.

Edit:

I added the IFDEFs at the beginning of my main file. Here the results:


1. When I use the single compiler call you gave me above, with the JEDI SDL headers (not the ones included in FPC), the game compiles and links, but crashes as soon as it tries to call SDL_INIT.

2. When I use your build script, it tells me:



Linking fprl
ld: warning: in ./libSDLmain.a, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
"_main", referenced from:
__start in crt1.o
(maybe you meant: _SDL_main)


So nothing has changed.

The libSDLmain file was created by me some days ago using the "devel-lite" folder in the SDL for Mac download, and using the following compiler call (as stated in the FreePascal wiki):



gcc -c -o SDLMain.o SDLMain.m -I /Library/Frameworks/SDL.framework/Headers
ar r libSDLMain.a SDLMain.o
ranlib libSDLMain.a


But somehow the resulting library seems not to be correct.

Stoney
09-01-2011, 09:47 AM
The problem seems to be that the libSDLmain.a you made is 64 bit, which is done by default if you have Snow Leopard installed. You need to explicitly compile the library for i386 and PowerPC if you plan to make Universal Binaries.
You can have my libSDLmain.a (it has i386, x64_64 and ppc all in one file): Download here (http://www.freeze-dev.com/temp/libSDLMain.a)

Edit: If you use my build script you might want to change CFBundleIdentifier and CFBundleSignature for your application. :)

Mario Donick
09-01-2011, 12:23 PM
Yes!! Stoney, this did the trick! :-D

Stoney
09-01-2011, 12:35 PM
Awesome :) I guess we really need a tutorial for new Mac OS X users.
Btw: If you would want or need to compile libSDLmain.a for yourself for i386 and ppc platforms you need to call this line


gcc -c -o SDLMain.o SDLMain.m -I /Library/Frameworks/SDL.framework/Headers

with an additional --arch i386 or --arch ppc parameter depending on which platform you need.

code_glitch
09-01-2011, 12:41 PM
Sweet - so I guess this is solved now! Hooray!

Quick note to apple: Windows users have functionality disabled in their versions of windows (unless you have ultimate). In your case, you either include functionality or you dont. For the next Mac OS X version - please include the functionality 'Common Sense' and 'Helpfulness'. I've never seen such a long thread for a simple linking issue. Apple: Pioneering in unexpected ways.

Stoney
09-01-2011, 01:19 PM
I've never seen such a long thread for a simple linking issue.

I guess if there was a tutorial for beginners on how to start with SDL and FreePascal on a Mac, most of this would be more clearer. Also FreePascal Mac support is quite new in regard to how long FPC for Windows and Linux have been around.
It was worse when I started with Mac development about 2 1/2 years ago, there was even less information back then.

Mario Donick
09-01-2011, 03:38 PM
Perhaps we should really write a good tutorial for beginners then. This might also include my next questions, regarding app bundles:

http://www.pascalgamedevelopment.com/showthread.php?6612-Distributing-Program-with-its-own-File-Structure-in-MacOS-Application-Bundle&p=52555#post52555

WILL
09-01-2011, 09:11 PM
All tutorials welcome by me. :) I'm building a new website dedicated as a guide for programming in Object Pascal for the Mac. (and iOS devices too!)

I've been chanting how useful it would be to have one for so long it was only time before I would eventually make one. ;) If you like, I can publish such an article on the site.