How do you set the main program in xcode when using pascal? - xcode

I am getting the following error using xcode with pascal:
warning: It seems your project only contains units and no main program
What causes this warning? And how do I set the main program?
I am using: Xcode 4.5.2, Free Pascal Compiler version 2.6.0, and Mac OSX 10.8.

If I understand the problem correctly, you're missing the .dpr (project file) that tells the compiler what type of project it should be building. The project file for Delphi (and the Borland Pascal and Turbo Pascal compilers before it) typically look something like:
{ For a GUI (Windows) application }
program MyProgram;
uses
Forms,
main in 'main.pas' {fMain};
{$R *.RES}
begin
Application.Initialize;
Application.CreateForm(TfMain, fMain);
Application.Run;
end.
{ For a console application }
program MyProgram;
{$APPTYPE CONSOLE }
uses
MyMain, SysUtils;
begin
try
{
Execute your application's entry point (main()) here, in this case
contained in MyMain.pas that's listed in the uses clause above.
}
except
{ Handle any exception here }
end;
end.
In Delphi XE2, you then run dpr2xcode.exe to create a corresponding Xcode project. (I don't know what the corresponding step would be in FreePascal, but you might look for something like that in your FP install.) Open that .xcodeproj file in Xcode on the Mac, and then run or debug the code.
For specific info on using FreePascal and Xcode, I recommend a series of articles by Phil Hess.

Related

Linking static library from Xcode into Lazarus app fails on architecture mismatch

Much research here and in-depth exploration via Google links, to no avail.
I've made a simple, one function, static C library with OSX Xcode (5) which I'm trying to link into a Lazarus app, basically to port the Xcode function from Xcode to Lazarus.
Xcode builds the static library alright, and I have what seems to be the proper linkage code in the Lazarus app, as follows:
type
byteptr = ^byte;
const
libname = 'libLORaudio.a';
function LORaudioPlay (fd : longint; audio : byteptr): Integer;
cdecl; external libname;
r := LORaudioPlay(e, z);
All of that compiles just fine, but the build fails with the following messages:
Id: symbol(s) not found for architecture i386
Id: Warning: ignoring file libLORaudio.a, file was built for archive which is not the architecture being linked (i386): libLORaudio.a
(and it goes on to say the function is undefined, of course, since it ignored the library that supplies it.)
My problem could be solved in either of two ways, neither of which have I found sufficient information on, online nor within Xcode or Lazarus.
One solution would be to get Xcode to produce the static library with the architecture expected by Lazarus. I have tried the various options for setting the build architectures in Xcode mentioned in other answers here to similar questions, but it seems I haven't done them correctly because none of them worked for me.
The other solution would be to get Lazarus to accept the architecture produced by Xcode. The Laz.y documentation is not helpful in this regard.
Any suggestions I could try? Thanks so very much for your consideration.
So eventually, I scrounged around with Finder and found where (see below) I had built both the x86_64 and the i386 object files in separate attempts to solve the problem. This was done by changing the build settings for Architectures to 'i386'. Subsequent re-builds for 'x86_64' didn't remove the i386 object info from earlier.
Then I copied the i386 object file into the folder containing the Lazarus project (it was necessary to make the copy with the alt-option dragging method, as copy then paste didn't work).
There, I ran ar on it in Terminal, as: 'ar -r -s libname.a name.o' to build the static lib from the object.
Lazarus now handles the library as desired. (This of course, revealed some other buggy situations to be dealt with, but hey, progress happens.)
Xcode had put both versions of the object in a folder. Find these products from Xcode by right-clicking on the product mentioned in the project navigator and choose 'show in finder'. You can do this for whichever architecture you currently have; both lead to the same build folders. From there work your way back up thru the containing folders until you spot Build. Open that and work your way forward among the contained folders until you get to Objects-normal. In there you'll find folders for i386 and x86_64. Each of those folders contains the corresponding object file as name.o among other product related files.

SDL-2: Trouble running native cocoa application in OS X

I'm curious if anybody could help with a problem I'm having. I just downloaded and installed the SDL 2 framework, along with the example programs that come with it, from Mercurial (http://www.libsdl.org/hg.php) onto OSX Mavericks (10.9).
I am attempting to run the example native cocoa code in Xcode 5.1.1, which includes the files testnative.h, testnative.c, and testnativecocoa.m that come from the tests folder in the Mercurial download.
I am successfully able to build the program, but as soon as it hits the function SDL_CreateWindowFrom(native_window), the program crashes and highlights the following line of a file called SDL_cocoakeyboard.m:
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow; Thread 1:EXC_BAD_ACCESS (code=1, address=0x8)
The only thing I did with the original files was change the include headers from SDL.h and SDL_syswm.h to SDL2/SDL.h and SDL2/SDL_syswm.h in testnative.h. I've included both the cocoa and SDL2 frameworks in the program, and I turned off automatic reference counting, which was necessary to get the example code running.
I have no idea where else I could be going wrong, since the code before the aforementioned line looks and runs fine (it's able to create the cocoa window before it crashes).
Any insight on this issue would be great. Thanks in advance!
I was wrong in the comment, driverdata is null (never initialized), some code like SDL_cocoawindow.m:SetupWindowData would be required, but SetupWindowData is static (not global) and adding a minimal initialization would require SDL_cocoawindow.h(but isn't public).
So, my guess (maybe I'm wrong) this testnative isn't working, at least not with current SDL2 (the wrong #include should have been a sign) but a fast look into SDL2 shown there's enough cocoa code to hope there are other ways to get a native window working.
A good start How to set up a SDL 2 project for OS X in Xcode 4

How can I retrieve the command line arguments from a program shortcut in the dock?

My question is the exact opposite of this earlier one. I am working on an open source application, which is published under 2 forms, pre-compiled binaries and source code.
I installed the pre-compiled binaries and it works perfectly, with a nice little icon in the dock.
I compiled the source code successfully, but I get a runtime error when I launch it. After investigation I suspect this app needs command-line options to run correctly.
So my question is: if my assumptions are correct and the working version is actually defining command line arguments, how can I retrieve the CL arguments from the packaged app?
If it makes any difference, the app I'm talking about is Cyberduck, and I'm running OS X Version 10.8.2
The issue is not the command line. From the code here
// Get an instance of the non-localized keys.
CFDictionaryRef bundleInfoDict = CFBundleGetInfoDictionary(mainBundleRef);
if(NULL == bundleInfoDict) {
fprintf(stderr, "[Launcher Error] No info dictionary.\n");
exit(-1);
}
where mainBundleRef refers to the .app bundle.
The problem is that the Info.plist inside the app (/Applications/Cyberduck.app/Contents/Info.plist) does not have the normal keys in it. It has been corrupted in some way.The one in the code repository looks OK at a glance. For information about the structure I would look at the Apple development document.
The easiest fix would be to redownload and install the application.

My Delphi 7 application halts on Application.Initialize and does not return to next line

I have created an application on Delphi 7. my app had running fine since yesterday. I don't know what's happened yesterday which cause my application halts on Application.Initialize line in source code and does not return to next line when i trace the program. I can't run the created executable file from widows niether while the generated file does run on another machine correctly. here is the code where the compiler stops on it:
program Info_Kiosk;
uses SysUtils, Forms, ... (some other units) ;
{$R *.res}
begin
Application.Initialize;
Application.CreateForm(Tfrm_Main, frm_Main);
any help would be appreciated
The implementation of TApplication.Initialize looks like this:
procedure TApplication.Initialize;
begin
if InitProc <> nil then TProcedure(InitProc);
end;
So, look through your code for anything that assigns to InitProc.
Another approach is to use your debugger to help you. Enable Debug DCUs. Then set a break point on the call to Application.Initialize in your .dpr file. Then step into that procedure with F7. Then step into the call to InitProc and follow that along until you reach the code that blocks.
If you are using a revision control system you can simply check out older versions of the project and use a binary search to find the commit that introduced the behaviour. If you are not using revision control, start doing so now.

Correct way to export a DLL function on Mac OSX

I'm trying to compile a simple DLL on a Mac OS X 10.6, and am confused about the proper way to declare a function that the DLL offers up for the world to use. Following sample code from a reliable source, I came up with:
__declspsec(dllexport) pascal int ReturnTheNumberFive(void)
but gcc barfs on it. What the sample code actually had was MACPASCAL and DLLExport, which I assumed were macros. I grepped through the sample codes, SDKs, etc for #defines and plugged in what I found. These definitions could have been buried inside #ifs, so what I found isn't good and true. Illogically, the compiler also barfs if I just do the obvious and use DLLExport and MACPASCAL, so that's no solution.
What is the correct way to make a DLL's function available to apps?
By default, all symbols are visible in a .dylib. There are no calling convention changes (such as Pascal calling convention)
So, in short:
int ReturnTheNunmberFive(void) { return 6; }

Resources