PDA

View Full Version : Problem with FreePascal + MacOS



Relfos
02-02-2011, 10:24 PM
I'm currently trying to port my engine to MacOSX (Snow Leopard).
The problem is, while everything compiles ok, there are bugs everywhere, everything crashes even in places it shouldnt!
Even during program startup, just calling SetLength twice on the same array (for redimensioning it) causes a crash.
Also using {$APPTYPE GUI} does not work, my program still brings up a console when run.

I can't post the code, because it is huge (about one hundred .pas files).
I've ported the engine successfully in the past to nintendo DS, and Linux, with no problems of this kind.

I'm using $mode DELPHI for everything, if this makes any difference.
And I'm running it from the command line (I was using -XX and -O2, but now tried even without those, and it has the same problem)
I could try Lazarus, however my program does not use a GUI (well, it usually creates a openGL window, but even now I'm just compilling the hello world, that just uses a logger class and nothing else)

Is there something different to take care when compiling for mac?
Or is the compiler not compatible with snow leopard?
Or is this some know bug?

Help :(

code_glitch
02-02-2011, 10:42 PM
Is there something different to take care when compiling for mac?Although I do not know all of the specifics, to that statement I would answer: more than you can possibly imagine. It is not necessarily a different way to do it the problem lies more in the fact that when something goes wrong forget your nice $message windows gives you or your segfault. Ever heard mac never crashes (although I beg to differ) it continues - good luck. I have seen so many mac issues in these forums it makes my head spin.

If you use the fp editor I know there is a debug compile option - I would say try it because it works in my cases to make things just that much more stable. Otherwise WILLs the guy to see or anyone else with a mac. Or perhaps you would consider making the jump to linux and all its open-source goodness? Slackware, Arch and Ubuntu: its all good.

Did you ensure the dev libraries are installed for the units you use and more importantly those .so (dyna-thingy lib on mac I think) are in place? The above happens on linux too if you dont have the libs ;)

Not much help I know, but I'm no mac fanboy but its a mac thread so posting is mandatory :)

edit: hey, now I think of it, wasn't it you that uses Arch Andru? That part of your avatar looks familiar...

PS: Have been looking into arch myself - what your idle ram on those machines? I must be honest though - I am looking into compiz ;)

Andru
02-02-2011, 10:59 PM
Also using {$APPTYPE GUI} does not work, my program still brings up a console when run.
Do you know what is "Bundle" in MacOS X world? :)


but even now I'm just compilling the hello world, that just uses a logger class and nothing else
I think there is a problem with this "just hello world" and "just a logger class". Try to do something separately from your engine.



hey, now I think of it, wasn't it you that uses Arch Andru? That part of your avatar looks familiar...
Yes, I use ArchLinux x86_64 on my desktop and laptop.

what your idle ram on those machines
Desktop and laptop has 4GB, so I never checked how much free RAM I have :)

Relfos
02-02-2011, 11:04 PM
Moving to Linux is not an option, actually this code already compiles on linux, this is a game engine that should run on all major operating systems, and only Mac is left now.
I actually bought a Macbook just for this, it has all latest updates and such, and enough ram, and latest FPC installed.

I don't know what a 'Bundle' is, I'll read about it, but for now just a simple console application should run.
Tomorrow, I will try to create a application from scratch that reproduces the error, without using the engine.

Andru
02-02-2011, 11:14 PM
I don't know what a 'Bundle' is, I'll read about it, but for now just a simple console application should run.
About "Bundle" I remembered because of your problem with "my program still brings up a console".


Tomorrow, I will try to create a application from scratch that reproduces the error, without using the engine.
Sometimes starting something from scratch is better then trying to modify something huge :) Good luck with your experiments.

Relfos
02-02-2011, 11:32 PM
I'm having no luck finding what a bundle is. When I talked about that, was about the {$APPTYPE CONSOLE} and {$APPTYPE GUI}, I'm using the later, and from what I read it is supported on darwin, however, when I double click the executable, a console window opens.

Another thing I remembered now, maybe I'm compiling for 64bits?
All other ports I have done are 32bits, and the code itself uses lots of pointer hacks that would probably crash under 64bits.
How to compile a 32bits application under snow leopard, is that even possible?

JSoftware
03-02-2011, 12:08 AM
Passing the -Wb compiler switch will create a bundle

WILL
03-02-2011, 12:11 AM
By 'Bundle' I believe that he simply means the way an "App" is packaged...

All those neat little App-like files that you just drag and drop into your Applications folder are really just fancy folders that contain files, yet act like an executable file. If you hold down the Option button while you right click on an "App" you'll see the option "Show Package Contents" to see the contents. If you select this you can go in and modify the contents. If your case add textures, audio files, etc...

Relfos
03-02-2011, 11:44 AM
I found the problem, guys.
The problem is the unit cmem!
I included it because I read that when using fpc threads we should include cthreads and cmem units as the first units in the program.
But this breaks the program everywhere, things like SetLength fail, for example.
FPC bug, or cmem is not needed anymore, or something else?

Andru
03-02-2011, 12:43 PM
Hm, I never used cmem, and my apps worked fine on Linux and MacOS X :) But if you need it, maybe you forgot that cmem unit should be the first unit in the uses clause?

Relfos
03-02-2011, 01:01 PM
Yes, but do you use TThread?
I don't really need cmem unit, so if you can use threads without it, better.
Also, I can't really get a single window application running, APPTYPE seems to don't work in MacOS?
My application now opens both a Carbon window and a console window, and while the console is useful for printing info, I want to be able to choose between having it or not.
Any special switch I need to compile?
(I don't use SDL or anything else, I create my window directly using Carbon, the code was based on a C++ sample I found on the web.)

Andru
03-02-2011, 05:45 PM
Yes, but do you use TThread?
For sound streaming I use BeginThread. And I add unit cthreads to my uses clause.


APPTYPE seems to don't work in MacOS?
If you were read FPC documentation, you would know this... :)


Also, I can't really get a single window application running, APPTYPE seems to don't work in MacOS?
GUI applications under MacOS X are not an one single executable. You must "build" your own Bundle (http://developer.apple.com/mac/library/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html). Simple description "what is Bundle" can sounds like this: "Bundle is a directory with name which contains part "name" and ".app"(for example - MyApp.app). Inside this directory must be another one - Contents. Inside Contest must be directories Frameworks(for your libs/etc.), MacOS(for your executable, which must be with the same name as your bundle, in our case - MyApp) and Resources(where you must put all your resources)".

Relfos
03-02-2011, 05:47 PM
Thank you, so I only need cthreads :)
And, if I understood correctly, what I need to hide the console is create a bundle for the application?
Seems simple, I will try.

Andru
03-02-2011, 05:51 PM
And, if I understood correctly, what I need to hide the console is create a bundle for the application?
Yes, you need to create your own bundle for application :)

Relfos
03-02-2011, 06:45 PM
Thank you so much, my Bobs game is now working on Mac :D
The only problem is I still can't get the keyboard input to work, I will try to look into Lazarus sources to see how they handle keyboard events in Carbon.
I know people will call me masochist for not using SDL, but in iPhone SDL needs a paid license for comercial projects, and I don't want to shell out 500$ for one, so I'm writing my own window/event handling for all platforms. Only iPhone and Wii to go :)

EDIT: Well, the keys are working now, it was just a stupid bug, one line changed and it is ok now.
Another problem, I have a method called Engine.Terminate that safely unloads all resources and uses Halt to quit.
After calling Terminate() on MacOS, it shuts down, but the operating system says "This software did not terminate correctly, open again or ignore?"
Should I pass another a specific value to halt() instead of zero?

Andru
03-02-2011, 07:10 PM
The only problem is I still can't get the keyboard input to work, I will try to look into Lazarus sources to see how they handle keyboard events in Carbon.
For Carbon you need to process kEventClassKeyboard event.

Relfos
03-02-2011, 07:14 PM
For Carbon you need to process kEventClassKeyboard event.
Yes, I was already using that.
The new problem, when calling Halt(), I get the message "Three Bobs quit unexpectedly, open again or ignore?"
Do you know what is the problem?

Andru
03-02-2011, 07:24 PM
Do you know what is the problem?
I don't know how exact you use Carbon(with your own main loop or with RunBlaBlaBla from standard Carbon API), so I can't answer you :) Anyway, halt is bad way to terminate your application.

Relfos
03-02-2011, 07:31 PM
Hmm, a bad way, why?
Before calling Halt() I release all allocated memory and resources, and destroy the Carbon window, well, maybe there is still something left to release, and that is causing the problem.

Andru
03-02-2011, 07:55 PM
Hmm, a bad way, why?
Because of "maybe there is still something left to release", but halt terminate your application immediately.

JSoftware
03-02-2011, 10:14 PM
I think, traditionally, Halt is used to preemptively terminate a program. It should of course work okay, which could indicate a bug in the termination code. But usually would use just exiting the normal "PASCALMAIN" procedure as usual

Stoney
04-02-2011, 03:47 AM
I know people will call me masochist for not using SDL, but in iPhone SDL needs a paid license for comercial projects, and I don't want to shell out 500$ for one, so I'm writing my own window/event handling for all platforms. Only iPhone and Wii to go :)


You got the prices wrong. One SDL iPhone license costs 100$ and -10% for every following iPhone license you purchase and finally down to 50$. I know it, I bought a license. :)
Also your Carbon code won't work on the iPhone as only Cocoa is allowed on iOS. Carbon has marked as deprecated by Apple since Mac OS X 10.5.
For Cocoa you should take a look at Objective-Pascal.

Relfos
04-02-2011, 12:31 PM
Oh I see, it's not that bad then, but since I already have code for all SOs, well, I just need to switch from Carbon to Cocoa then.
Hmm, objective Pascal, does FPC have Cocoa headers?

WILL
05-02-2011, 05:01 AM
This has probably been found by any of those looking into Objective-Pascal or Cocoa for Pascal, but here it is just the same: http://wiki.freepascal.org/FPC_PasCocoa

It outlines the initial idea behind Objective-Pascal and how it was implemented by the Free Pascal compiler team. It also tells you how to enable it for your projects too.

Relfos
05-02-2011, 09:35 AM
Thanks! I've been reading about Cocoa, and Objective Pascal, and how it all works, I still need some days to understand it correctly.
My next question, tough, this should be probably in a new topic:
Today I managed to compile a Free Pascal program for iPhone using XCode and the included template.
However when reading the code, I found that it was not 100% pascal, at least half of the code were Objective C, and the pascal code was declared as external in a library.
I understand how this works, but is it the only way?
Or can one create an app for iPhone that uses only pascal, and is compiled just using the command line?

Stoney
05-02-2011, 06:47 PM
I understand how this works, but is it the only way?

There are two other ways:
1. Use SDL which takes care of most things. Remember, you can use SDL free of charge if you're application is released as GPL, only if you to release your application as freeware or commercial you need to buy a license before the application is released.

2. Use Objective-Pascal as explained here: http://www.thealchemistguild.org/pascal/ <-- Take a look at the iArkanoid example.

Relfos
06-02-2011, 06:48 PM
Thank you Stoney, I did not know that website, it contains really useful information :)
I'm planning to release comercial applications, but SDL price is okay, I will look how much work is needed to replace it tough.

Ingemar
03-04-2011, 06:29 AM
Thanks! I've been reading about Cocoa, and Objective Pascal, and how it all works, I still need some days to understand it correctly.
My next question, tough, this should be probably in a new topic:
Today I managed to compile a Free Pascal program for iPhone using XCode and the included template.
However when reading the code, I found that it was not 100% pascal, at least half of the code were Objective C, and the pascal code was declared as external in a library.
I understand how this works, but is it the only way?
Or can one create an app for iPhone that uses only pascal, and is compiled just using the command line?

You mean the Objective-C library called FPC code? I have messed a lot with mixing C and FPC code, and recently learned the right way to do that, and that is indeed to put all the FPC code in a separate dylib library (shared library). It is theoretically possible to do static linking, but don't even try, it is not worth it.

However, the Objective Pascal dialect works very well (Stoney's suggestion #2). That's what you should use. It is still changing, which can be a bit frustrating at times, but it works.

Andru
03-04-2011, 06:42 AM
to put all the FPC code in a separate dylib library
Not a solution for iOS, where dylib's are not allowed.

Relfos
03-04-2011, 08:20 AM
I don't know if I already said so, but I got this working, for both Mac and iOS (here I use the solution of mixing pascal with Objective-C, since I had some problems with the objective pascal compiler). I will probably try to move into Objective Pascal later tough.

Ingemar
06-04-2011, 04:45 PM
Carbon has marked as deprecated by Apple since Mac OS X 10.5.
For Cocoa you should take a look at Objective-Pascal.

Actually, the deprecation stigma has been vague at best concerning Carbon. Up to 2007, Carbon was a "prime citizen", although Apple engineers kept recommending developer to move to Cocoa. Then 64-bit Carbon was cancelled, but Carbon was still not officially deprecated. Some parts, like QuickDraw, are officially deprecated, but a lot of stuff is, as far as I can tell, in a strange non-deprecated state despite 32-bit only, while Apple is silently removing support for it. "Carbon" gives fewer and fewer hits on Apple's pages. Of course, part of the confusion is the vague border between "Carbon" and "Core". File Manager and Resource Manager are pre-Carbon/Carbon managers but are now "Core".

In practice, however, Carbon was deprecated when 64-bit Carbon was cancelled, we all know that.

I have been working quite a bit on finding a nice path from Carbon to Cocoa, and the result, the Cocoa version of the old TransSkel framework, complemented with some Carbon-style functionality (including QuickDraw!) is getting pretty good. However, the process of installing Objective-Pascal (with its Cocoa interfaces) is not perfect, but once you get it right it is quite nice and works amazingly well. Unlike Objective C, Objective Pascal syntax is not a confusing mix between two languages.