Hi,

I followed the instructions on the Wiki to create a cross-compiler for Windows.

http://wiki.lazarus.freepascal.org/Cross_compiling#To_Windows

My current system is Ubuntu 64bit with FPC 64bit. I'm cross-compiling my projects to Win32 from inside the IDE.

I have managed to successfully cross-compile my projects, but the process is definitely not simple or quick. Is there some better way of doing this from inside the IDE?

Currently I have to following these steps:

1) Manually created a cross-compile script for fpGUI Toolkit, because Lazarus Packages don't seem to support different files for various platforms. So I have two .lpk files for Lazarus. One for Linux and one for Windows.

2) Due to the above problem, I can't include the fpgui_toolkit.lpk packages as a dependency to my project when I cross-compile. So I have to remove the dependency first (By thew trunk Lazarus crashes with AV when I remove it. On restarting the IDE, I can remove it successfully).

3) Environment Options: Change Compiler path and FPC Source Path.

4) In my Project Compiler Options dialog, go to Code tab and change target platform and CPU to 'Windows 32' and 'i386'. Remember, by current setup is Linux with 64bit FPC.

5) Then due to issue (1), I have to manually add a -Fu<path> in the Project Compiler Options dialog - Other tab.

6) If fpGUI code changed, manually run the cross-compile scrip.

7) Click Compile in Lazarus.

Finally I have a Windows 32bit executable.

Now if I want to continue with Linux + 64bit development in my project, I have to undo all the steps above before I can recompile. This process is extremely tedious.

Is there ANY better or faster way of doing this? My next step is to simply create a cross-compile script for my project as this will be MUCH quicker that the process above.

Regards,
- Graeme -

What support do you expect? Almost all packages in the components dir are cross platform, take for example printers4lazarus package.

3) Environment Options: Change Compiler path and FPC Source Path.

Why? Just choose fpc as compiler and let fpc call the ppcXXX compiler based on the -P parameter.

4) In my Project Compiler Options dialog, go to Code tab and change target platform and CPU to 'Windows 32' and 'i386'. Remember, by current setup is Linux with 64bit FPC.

These steps are indeed necessary.

5) Then due to issue (1), I have to manually add a -Fu<path> in the Project Compiler Options dialog - Other tab.

IMHO (1) is not an issue.

6) If fpGUI code changed, manually run the cross-compile scrip.

Why don't you let the IDE recompile the package?

7) Click Compile in Lazarus.

This step is indeed necessary.

Finally I have a Windows 32bit executable.

No, just step (4) and (7). (4) could be made a bit faster using the build mode feature.

Is there ANY better or faster way of doing this? My next step is to simply create a cross-compile script for my project as this will be MUCH quicker that the process above.

Maybe.

Vincent

Zitat von Graeme Geldenhuys :

It should be possible.
Have unchecked 'use unit'?
What error do you get?

2) Due to the above problem, I can't include the fpgui_toolkit.lpk packages as a dependency to my project when I cross-compile. So I have to remove the dependency first (By thew trunk Lazarus crashes with AV when I remove it. On restarting the IDE, I can remove it successfully).

Can you reproduce the problem?
Can you send me a backtrace?

3) Environment Options: Change Compiler path and FPC Source Path.

Or use 'fpc' as compiler.
Why change FPC source path?

(1) should not exist, so (5) is not needed.

6) If fpGUI code changed, manually run the cross-compile scrip.

same: not needed, when normal package is used

7) Click Compile in Lazarus.

yes, that is needed.

Help us to fix the above bug.

My next step is to simply create a cross-compile script for my project as this will be MUCH quicker that the process above.

Mattias

I knew after I posted the message that I would have to explain this one. :-) Just solving this step would already reduce the cross-compiling effort, but I don't have a solution yet.

Below is a partial layout of fpGUI project directory, to help explain my reason for multiple .lpk files - one for each backend (platform).

/home/graemeg/programming/fpgui
.
|-lib
|---i386-linux
|---i386-win32
|---x86_64-linux
|-src
|---corelib
|-----gdi
|-----x11
|---gui

All sub-directories inside 'lib' are created by Lazarus. 'lib' is where all compiler unit files end up. eg: *.ppu *.o etc..

The 'src' directory is the tricky one. Here I am not sure if Lazarus Packages support what I need - or maybe I can change my code to accommodate Lazaurs IDE. Not sure.

Inside the 'gdi' directory is the fpgui_toolkit.lpk file for Windows. Inside the 'x11' directory is the fpgui_toolkit.lpk file for Linux & FreeBSD. So now any fpGUI based application (windows or linux) refer to 'fpgui_toolkit.lpk' as a dependency package without problems. Inside the 'corelib' is all the common (platform independent) code, and then backend specific code is either in 'x11' or 'gdi'. For example, I will have a unit defined in 'corelib'. It's Interface section is common to all platforms, but for the implementation section I will have a include file only. The include file will be located in the backend specific directories (x11 or gdi).

Also, each platform specific .lpk file will also include its platform specific units. For example, under 'x11', I include some custom Xlib header translation, XFT header translation and X11 NetManager implementation files, which are obviously not related to Windows, so only appear in the X11 supported platform package.

If I translate the above to FPC command line parameters (like I have in a extrafpc.cfg file), I have this layout.

-----------------------
# searchpath for include files
-Ficorelib
#IFDEF X11
-Ficorelib/x11/
#ENDIF
#IFDEF GDI
-Ficorelib/gdi/
#ENDIF

# searchpath for units and other system dependent things -Fu.
-Fucorelib/
#IFDEF X11
#WRITE Compiling X11 CoreLib
-Fucorelib/x11/
#ENDIF
#IFDEF GDI
#WRITE Compiling GDI CoreLib
-Fucorelib/gdi/
#ENDIF
-Fugui/
-Fugui/db/

# Unit output path
-FU../lib/$fpctarget/

-----------------------

So how can Lazarus Packages support my requirements? Alternatively, is there another way I can restructure my code - but I can't really see how.

> 3) Environment Options: Change Compiler path and FPC Source Path. Why? Just choose fpc as compiler and let fpc call the ppcXXX compiler based on the -P parameter.

I have had problems with 'fpc' on my system, so for some reason I only have ppcXXX files. I'll try and recompile my FPC again to see if I can resolve this issue.

The reason for the Source Path change is because I use FPC 2.2.5 to compile FPC 2.3.1 (64bit). So for 64bit (linux) work, I mainly use FPC 2.3.1 code. And because FPC 64bit executable cannot create a cross-compiled FPC 32bit executable, I keep using the 2.2.5 for 32bit development. So I used FPC 2.2.5 (32bit linux) to cross-compile a FPC 2.2.5 windows 32bit compiler.

I did post a question in the fpc-users mailing list as to why 64bit FPC cannot create a 32bit FPC, but vice-versa is possible.

I suppose if the IDE supported Build Modes like MSEide, this would have made things much simpler. Simply select Run and then any of the build modes you setup in the menu.

> 6) If fpGUI code changed, manually run the cross-compile scrip. Why don't you let the IDE recompile the package?

As I explained above. It's a bit more complex, using different units per platform and using different include paths per platform. I'll take a look now at the printers4lazarus packages you mentioned. Maybe that will give me some hints on how I could solve issue (1).

Regards,
- Graeme -

Mattias G?rtner wrote

It should be possible.

Even with different include paths per platform?

Have unchecked 'use unit'?

Yes, it's unchecked. I did so to optimize linking and produce smaller executables - which only include the units it really needs. But if I need to enable this again, it's not a problem really.

What error do you get?

Can't find units because of wrong include paths being used and then the windows cross-compilation complains about 'unit x' not being found. I also have to do some trickery with the platform types. So I have a "alias" types defined in each backend (platform specific) directory. But the unit name is the same for all platforms.

eg:
Both of these have the same unit names and same types, but based on the platform, they translate to something different.

------------[ corelib/x11/fpg_impl.pas ]--------------
unit fpg_impl;
{$mode objfpc}{$H+}
interface
uses
  x;
type
    TfpgWinHandle = TXID;
    TfpgDCHandle  = TXID;
implementation
end.
------------------------------------------------------
--------------[ corelib/gdi/fpg_impl.pas ]-------------
unit fpg_impl;
{$mode objfpc}{$H+}
interface
uses
  Windows;
type
    TfpgWinHandle = HWND;
    TfpgDCHandle  = HDC;
implementation
end.
-----------------------------------------------------

> to remove the dependency first (By thew trunk Lazarus crashes with AV > when I remove it. On restarting the IDE, I can remove it successfully). Can you reproduce the problem?

Yes, I can reproduce every time, and on IDE restart it works.

Can you send me a backtrace?

I do so after this email, using a new subject.

Or use 'fpc' as compiler. Why change FPC source path?

As explained in my previous reply. FPC 64bit with uses 2.3.1 cannot cross-compile a 32bit FPC for 2.3.1. So I went back to linux 32bit FPC 2.2.5 to cross-compile FPC 2.2.5 32bit windows compiler.

> 7) Click Compile in Lazarus. yes, that is needed.

You and Vincent think the same! :-)

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

You have a custom set of platforms (values: x11, gdi). Just like the LCL widgetset.
At the moment the LCL widgetset is hard coded into the IDE and packages can not yet define their own 'platforms' (they will be called build variables).
So you can not yet easily switch your custom platforms.

Using two different lpk is a good solution.

Of course you can write a designtime package and install an speedbutton and/or menu item to switch between the packages. If they have both the same name, a simple open package should be enough.

fpc has evolved in the last years.

You can use the macro $(FPCVer) in the FPC source path of lazarus.

I did post a question in the fpc-users mailing list as to why 64bit FPC cannot create a 32bit FPC, but vice-versa is possible.

Can someone confirm, that the 64 bit ppc can compile 32 bit code?

Yes, this planned.
I already started the internals. Maybe 50% already works.

printers4lazarus uses the TargetOS and LCLWidgetType macros.

Mattias

Ah, so I wasn't simply overlooking some IDE feature. :)

What is the CodeTools Defines Editor dialog used for? I don't seem to be allowed to edit anything in there, even though the dialog title says "editor". See attached image. I thought maybe I could define some macro or something in there, but like I said - no luck trying.

Using two different lpk is a good solution.

I also created a linux/windows build script and a fpmake.pp unit to compile fpGUI from the command line. This often makes it a bit easier to switch targets (compared to the current IDE) - like in the case of cross-compiling. But then again, this doesn't happen to often in my case.

speedbutton and/or menu item to switch between the packages. If they have both the same name, a simple open package should be enough.

I was wondering what would happen if I opened the Windows .lpk while under Linux. :-) But then I thought I better not try, because it might break something or change paths etc.... I'll give this a go, and can always revert changes using my repository tools.

You can use the macro $(FPCVer) in the FPC source path of lazarus.

I already do for standard FPC builds, but wasn't sure if the cross-compiler (ppcross386) is going to play along. I'll experiment some more.

That's excellent news! :)

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

It shows, what the IDE sets up behind the scenes. Just like the IDE is a frontend for gdb and fpc, it is also a front end for the codetools. For example if you have Delphi you can add defines for the Delphi sources, so you can browse them.

It will load the windows lpk. Opening a package does not change any file (except for the IDE history lists). Of course some macro values will change like unit paths and include paths.

Mattias