Compile/Convert Delphi project to MacOS

[Joseph]

Hello ,

(beginner's question) I have a compiled Delphi project that works as expected on a Windows. I'd like to use the source code to compile it for the Mac as well, but I'm at a sticking point.

The project basically contains 6 .pas files and 1 .dpr file.

I have installed Lazarus (following the tutorial here
https://wiki.lazarus.freepascal.org/Installing_Lazarus_on_macOS), then FPC.

I then converted the Delphi project into a Lazarus project using the tool provided in Lazarus. It worked as expected (some modifications in the files and appearance of a .lpr as well as .lpi etc).

I then try to compile the project. I've tried both "Compile" and "Clean up and Build", but both lead to the same errors after about 10/15 seconds of compilation:

- Error: -macosx_version_min has been renamed to -macos_version_min
- Error: linker: Undefined symbols for architecture x86_64:
- Error: linker: "WSRegisterBevel", referenced from:
- Error: ld: symbol(s) not found for architecture x86_64
- and finally: Error: Error while linking

There is definitely something related to the linker, but I can't find what the problem actually is and/or what should I do.

I should point out that I've managed to compile and run simple hello world type programs without any problems.

I use:
- MacOS Sonoma 14.4.1
- Lazarus 3.2
- FPC 3.2.2

Any hint or help would be highly appreciated 

[TRon]

Hello ,

Hi !

Any hint or help would be highly appreciated 

See thread.

[Joseph]

Thanks! It's probably the same issue I'm facing.

I'll continue the discussion there.

[Martin_fr]

Those linking errors could be caused by missing "interfaces"...

Probably something that went wrong during conversion of the project.

I am not 100% sure how to fix this (in an existing project)...

But when you do: Menu > Project > View project source  // last entry in menu
you should see something like

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   {$IFDEF UNIX}
7.   cthreads,
8.   {$ENDIF}
9.   {$IFDEF HASAMIGA}
10.   athreads,
11.   {$ENDIF}
12.   Interfaces, // this includes the LCL widgetset
13.   Forms, unit1
14.   { you can add units after this };
15.  
16. {$R *.res}
17.  
18. begin
19.   RequireDerivedFormResource := True;
20.   Application.Scaled := True;
21.   Application.Initialize;
22.   Application.CreateForm(TForm1, Form1);
23.   Application.Run;
24. end.
25.  

And it must have "Interfaces" in the uses clause.


The other part is in the menu Project > "Project options"
Tab: Compiler > Config and Target

It should say "Current Widgetset ... " And then allow to select another. Make sure it is "cocoa" (I assume that is what you target? otherwise...)

If that option is not there, someone else will have to look into how to fix it...
If the option is not there, then the project that was created is a console app, that has no GUI. It can probably be changed somehow....

[Joseph]

in Project Source I have:

Code: Pascal  [Select][+][-]

1. program lifelihoodC2023;
2.  
3. {$MODE Delphi}
4.  
5. {$APPTYPE CONSOLE}
6.  
7. uses
8.   SysUtils,
9.   Classes,
10.   Unit2 in 'Unit2.pas',
11.   Alea in 'Alea.pas',
12.   fmath in 'fmath.pas',
13.   fspec in 'fspec.pas',
14.   mathromb in 'mathromb.pas',
15.   Unit1 in 'Unit1.pas';
16.  
17. begin
18.      

Should I manually add Interfaces?

Current LCL widgetset: "cocoa"
--> seems right

[Martin_fr]

Should I manually add Interfaces?

Its worth a try. And check that "Application" is "Run" as in my example, and the form is created.

Also "{$APPTYPE CONSOLE}" seems wrong (but may still work).  Well => that is, your app has forms?

Mind, that my answer is partly guessed... I mainly work on other parts of Lazarus...

[Joseph]

So here's what change:

- The project does not use forms.

- Adding Interfaces seems to improve (or at least change the error). Project seems to compile until error1.png (see joined img), and 'continue' leads to error2.png (see joined img).

- No more previous errors on linker

I have a meeting tomorrow with the creator of this project, so maybe I'll have some other info or relevant input from him to add here.

[Martin_fr]

If you don't use forms....

then you shouldn't need cocoa related code.... Well except, maybe timers, or there are a few things that you could use without GUI that still need code that  knows about GUI...

Some of your units, would use the package LCL or LCLBase (or a package that then uses either of those). Question is, if that unit is used for a reason, or was added by accident.
If the latter, then if you remove all LCL dependencies, and remove the package from the list of required packages, then you don't need interfaces => and your app will become quite a bit smaller.

For the rest... Out of index error => that is something wrong in your code (or code that you called).

Index 0 out of bound => list is empty.

Don't continue, press "break" and it should show you the code that causes the error. Though sometimes you need to open the "stack window" and find the code in the list of callers.

[Joseph]

After my meeting, we decided to go back to the basics.

The project used to be based on GUIs, but that's no longer the case, so it's possible that bits of code have been forgotten in connection with that.

Thank you very much for your help! For the moment I'm going to try recompiling on Windows to see if the bugs recur or not, bearing in mind that I've already managed to get it to work on this OS.

I'll continue the discussion here when I have a better understanding of the problems if other people have a similar case. Thanks again Martin.

[Joseph]

So I think I made some progress.

What I did was:

-  take the delphi project on a Windows, compile it with embarcadero (delphi CE) and run it: works as expected.

- take the delphi project on a Windows, convert it to a lazarus project, compile it and run it: works as expected.

- take the delphi project project on a MacOS, convert it to a lazarus project, compile it and run it: doesn't work.

Message during compilation:

Code: Text  [Select][+][-]

1. Compile Project, Target: /Users/josephbarbier/Desktop/compile-lifelihood/compilation/setUp/lib/x86_64-darwin/lifelihoodC2023: Success, Errors: 1, Warnings: 3, Hints: 15
2. lifelihoodC2023.lpr(5,2) Note: APPTYPE is not supported by the target OS
3. Unit1.pas(22,5) Note: Local variable "i" not used
4. Unit1.pas(63,15) Hint: Local variable "vc" of a managed type does not seem to be initialized
5. Unit1.pas(41,11) Note: Local variable "t" not used
6. Unit1.pas(41,13) Note: Local variable "m" not used
7. Unit1.pas(41,15) Note: Local variable "n" not used
8. Unit1.pas(41,23) Note: Local variable "nbponte" not used
9. Unit1.pas(41,40) Note: Local variable "ii" not used
10. Unit1.pas(42,5) Note: Local variable "stop" not used
11. Unit1.pas(43,5) Note: Local variable "tabaux" not used
12. Unit1.pas(44,5) Note: Local variable "somme" not used
13. Unit1.pas(44,11) Note: Local variable "maxi" not used
14. Unit1.pas(46,11) Note: Local variable "checkpart" not used
15. Unit1.pas(211,7) Note: Local variable "j" not used
16. Unit1.pas(7,9) Hint: Unit "Alea" not used in Unit1
17. Warning: ld: warning: -multiply_defined is obsolete
18. Error: -macosx_version_min has been renamed to -macos_version_min
19. Warning: ld: warning: ignoring duplicate libraries: '-lc'
20. Warning: ld: warning: no platform load command found in '/Users/josephbarbier/Desktop/compile-lifelihood/compilation/setUp/lib/x86_64-darwin/lifelihoodC2023.or', assuming: macOS
21.  

I don't know if warnings/error should be my focus at the moment since it actually compiles.

But when I try to execute it:

Code: Text  [Select][+][-]

1. EAccessViolation: Access violation

, suggesting that the program tries to access invalid memory.

After some "print debugging" work, I was able to localise more or less what part of the code causes the error, but it's still unclear.

I put the project in public mode on my github repo with source code, data and executable if that helps (the easiest way to run the project is to use the .R file since the project uses lots of inputs): https://github.com/JosephBARBIERDARNAL/compile-lifelihood/tree/main

This part (https://github.com/JosephBARBIERDARNAL/compile-lifelihood/tree/main?tab=readme-ov-file#april-30) README contains an explanation with details of what I understand of the problem (which files may be concerned etc).

It's very unclear to me what causes error and why it only happens with macOS, so any hints or search direction will help me.

Thanks!

Note:
- MacOS Sonoma 14.4.1
- Lazarus 3.2
- FPC 3.2.2

[TRon]

Hi Joseph,

In unit2 of the converted project there is a list of units in the uses clause.

In that uses clause the units forms and grids are listed. If I understood correctly then these needs to be removed.

In that same unit2 you there is an implementation of the function f that has a line that reads:

Code: Pascal  [Select][+][-]

1. Application.ProcessMessages;
2.  

That can be removed (or commented) as well.

After these changes the project compiles from the command line with FPC on my Linux machine (there are still some warnings and notes, most notably the $N switch and apptype is not supported by target OS but these can be fixed as well).

edit:

In the main project file "lifelyhoodc2023.dpr" there we can read:

Code: Pascal  [Select][+][-]

1. {$APPTYPE CONSOLE}
2.  

to get rid of the APPTYPE message during compilation you can do:

Code: Text  [Select][+][-]

1. {$ifdef windows}
2. {$APPTYPE CONSOLE}
3. {$endif}
4.  

Regarding the $N+ switch in alea.pas I am not quite sure what to do because that seem to suggest the code is very old (mode tp) and afaik both Delphi and FPC should ignore this switch on modern compilers (but I seem to fail with a good suggestion how to get rid of the message because you might perhaps want to compile this with TP and using this switch)


edit2:
fwiw: Removing the units forms and grids also means you could get rid of the interfaces unit (the program does not seem to have a need for that at all). The forms and grids units probably caused the wsxxx messages during (earlier) compilation as described on the github repository.

[Joseph]

The main problem was actually with the forms, as well as certain warnings as you've just explained.

The project is working as expected! Thank you very much, that makes my day (or even my week actually). I am extremely grateful for the responsiveness and help of this site! So thank you again, everyone.

edit:
about the $N+ switch, I'm not sure what should it be. The project is old and ideally it should be modernised. Since I don't currently understand why is it here, I'll let it there for the moment.

[TRon]

The project is working as expected! Thank you very much, that makes my day (or even my week actually). I am extremely grateful for the responsiveness and help of this site! So thank you again, everyone.

Ah ok, thank you for the feedback.

Uhm... that raises the question what on earth does this program calculates that it takes 12 minutes (single core ofc) to be able to do so ? I am not a data analyst and the results were pretty much inconclusive for me 

edit:
about the $N+ switch, I'm not sure what should it be. The project is old and ideally it should be modernised. Since I don't currently understand why is it here, I'll let it there for the moment.

The N directive comes into play when deciding to use FPU floating point math or not, see also answer to undocumented compiler switches (Unfortunately I seem unable to locate formal FPC documentation on the matter, other than the non-informative part here)

[PascalDragon]

edit:
about the $N+ switch, I'm not sure what should it be. The project is old and ideally it should be modernised. Since I don't currently understand why is it here, I'll let it there for the moment.

The N directive comes into play when deciding to use FPU floating point math or not, see also answer to undocumented compiler switches (Unfortunately I seem unable to locate formal FPC documentation on the matter, other than the non-informative part here)

What's non informative about the switch only being recognized, but otherwise ignored? FPC doesn't provide any functionality behind it, so there is no reason to document any detailed functionality.

[TRon]

What's non informative about the switch only being recognized, but otherwise ignored? FPC doesn't provide any functionality behind it, so there is no reason to document any detailed functionality.

In basics you are entirely correct there PascalDragon.

From the documentation I assume the switch is only there for backwards compatibility without any functionality and that is more than fair enough.

However, as I see it, the 'problem' lies in the fact that I do not remember (anymore) what this switch did back in the day and obtaining relevant information about it seems to become more problematic with each passing day.

While I agree that is basically not a FPC related issue it poses an practical issue of not knowing what such a switch switch actually does (or did back in the day) and so are unable to work around or try fix things. It can simply be dealt with by stating that it is the programmer at fault for his/her lack of knowledge..... which in practice more or less completes the circle....