Cross compiling from linux64 to win64

[trev]

> ~/.lazarus/lib/LazUtils/lib/i386-win32 . But win64 is in the share dir!

I believe that Lazarus compiles in the ~/.lazarus directory ONLY when the /usr/local/share or /usr/share (depends on OS) directory is read-only which is the normal case wth any Unix-like OS.

It may therefore be you who created the  "mess" when you changed the read-only permissions on your /usr/share directory

[dbannon]

Code: [Select]

$ ppcrossx64
Free Pascal Compiler version 3.2.0 [2020/07/17] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
/usr/lib/fpc/3.2.0/ppcrossx64 [options] <inputfile> [options]
 Put + after a boolean switch option to enable it, - to disable it.
...

The  /usr/share dir is not under root privileges, nor it is any file here.

Sorry, I don't quite see the relevance of /usr/share here. But it definitely SHOULD be under root privileges.

When you initially did the first steps to create a cross compiler, you would have had to do that as root, correct ?

Are you sure that there was no prior install of FPC there ?  If all works well, all the FPC stuff ends up below the /usr file system. I cannot tell you exactly where as mine is all in user space (a practice I  recommend).

BTW, i386 comiled dir is here: ~/.lazarus/lib/LazUtils/lib/i386-win32 . But win64 is in the share dir!

The i386 files you see are Lazarus files, very important to remember that FPC and Lazarus are two different products.

I beleve the mess is made here by mixing directories by compilation process itself, which cannot be my fault as I did all by recommended guide.

I understand your frustration but I have installed it several times, lots of other people out there do so too. If we can get to the bottom of this problem, together we can improve the wiki documentation, thats how open source works.

Then, why when compiled cross-compiler for Win64 files are stored in share dir?

Sorry, don't understand. lazarus files are stored in $HOME/.lazarus, FPC are generated during that initial creation of the cross compiler, as root. And stored up in the /usr tree.

That probably makes real mess. Moving all win64 compiled dirs to ./lazarus by side of i386, then all will probably work.

I believe you are better having FPC files in user space and most certainly should have lazarus files there. But people like to install from Packages.....

Now, you keep mentioning the share directory, do you mean /usr/share ?  Thats where, in a package install, the FPC source ends up. You will compile a number of units as the there as the last stage of making the cross compiler. As root.

Davo

[process_1]

Trev: "It may therefore be you who created the  "mess" when you changed the read-only permissions on your /usr/share directory"

How can you be sure that devs are not messed up all that?

It is hardly possible that is my failt, since I didn't  messed with nor  changed any permisions, only installed exactly as I already shown upper.

How it is possible that cross-compiled files for Win64 are located in share dir, but i386 in ./lazarus dir? That is weird at least.

Devs, look at you scripts, please!

[process_1]

@dbannon

I have removed previously installed FPC and Lazarus with apt-get and removed manually ./lazarus.

I did seen some 3.0.4 residues in /usr/share dir I have removed manually.

Some other steps are required?

[dbannon]

It is hardly possible that is my failt, since I have not chaned any permisions, only installed exactly as I already shown upper.
How it is possible that cross-compiled files for Win64 are located in share dir, but i386 in ./lazarus dir? That is weird at least.

Because, as I just said, you are confusing FPC and Lazarus files.

I think personally, if you really do have a badly messed up install, especially if it has involved changing permission in places like /usr/share, then you may be better to remove it and start again.  I strongly suggest, given your need to install cross compilers that both FPC and Lazarus should be in user space.

Its a well documented process, involves a few medium to big downloads but you end up with a system thats easy to control and easy to modify.

And I can assure you, the FPC/Lazarus devs have not shipped packages that would change the permissions on any major root file system. Even the windows using ones. Ever !

Davo

[dbannon]

....
I did seen some 3.0.4 residues in /usr/share dir I have removed manually.
....

OK, now we are making progress.  First, I suggest you make sure you have removed everything associated with Lazarus and FPC and perhaps move $HOME/.lazarus

Then, three step process, install FPC, build Lazarus and then the cross compiler.

https://wiki.lazarus.freepascal.org/Installing_the_Free_Pascal_Compiler#FPC_Tar_Balls

https://wiki.freepascal.org/Installing_Lazarus_on_Linux#Build_Lazarus_from_Source

Then, the cross compiler. I will follow up on that shortly.

Davo

[Handoko]

Some other steps are required?

This is how to do the cleaning up:
https://forum.lazarus.freepascal.org/index.php/topic,42364.msg295596.html#msg295596

[dbannon]

OK, here are some notes I initially prepared to update the wiki but, as usual, never got around to it.  For a while I used fpc320 beta / rc1 and the note were not updated, sorry.  So, I have hacked away here, IT HAS NOT BEEN TESTED but you can see what we are trying to do, if you get a an error message, I am sure you will be able to adjust it accordingly.

This all assumes you have installed fpc and its source in the locations mentioned in the wiki page, if you have them somewhere else, you will have to adjust.  (You will probably need to adjust for my mistakes anyway !)

Installing Lazarus Cross Compiler

Mis named actually, Lazarus does not need anything done to cross-compile, everything you do is done to FPC and its friends. But do build Lazarus, one way or another, from source, you need it in user space.

Install FPC from a tarball, I will then build the Lazarus IDE from source so all lazarus files end up in my home directory and I don't need to mess with permissions to to change them. The alt is to use the sourceforge lazarus deb but I found that a bit constricting.

Setup Linux i386 compiler and Windows compilers

These are the dependencies for the i386 linux compiler.
apt install libc6-dev-i386  libx11-6:i386  libx11-dev:i386  libgdk-pixbuf2.0-0:i386  libatk1.0-dev:i386 libgdk-pixbuf2.0-dev:i386  libpango1.0-dev:i386  libgtk2.0-dev:i386 libnotify-dev:i386


we need libc6-dev-i386 (they are just little bash scripts that call ld and as with specific options), see if you have them already -
which i386-linux-ld
which i386-linux-as

If not, they could be installed under /usr but probably makes sense to do so in the same place we put FPC binaries, a place we will add to path, $HOME/bin/FPC/fpc-3.2.0/bin

cat > $HOME/bin/FPC/fpc-3.2.0/bin/i386-linux-ld
!#/bin/bash
ld -A elf32-i386 $@

cat > $HOME/bin/FPC/fpc-3.2.0/bin/i386-linux-as
#!/bin/bash
as --32 $@

chmod +x  $HOME/bin/FPC/fpc-3.2.0/bin/i386-linux-ld
chmod +x  $HOME/bin/FPC/fpc-3.2.0/bin/i386-linux-as



# Setup i386 underlying stuff
cd $HOME/bin/FPC/SRC/3.2.0/
make all CPU_TARGET=i386
make crossinstall CPU_TARGET=i386 INSTALL_PREFIX=/home/bin/dbannon/FPC/fpc-3.2.0

# Setup 32bit and 64 bit Windows
cd $HOME/bin/FPC/SRC/3.2.0
make clean all OS_TARGET=win32 CPU_TARGET=i386
make crossinstall OS_TARGET=win32 CPU_TARGET=i386 INSTALL_PREFIX=$HOME/bin/FPC/fpc-3.2.0/bin/

OK, we now have a working cross compiler, lets build the libraries

make clean all OS_TARGET=win64 CPU_TARGET=x86_64
make crossinstall OS_TARGET=win64 CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/bin/FPC/fpc-3.2.0/bin/
// ln -sf /usr/lib/fpc/$FPCVER/ppcrossx64 /usr/bin/ppcrossx64  // ignore, I think....

# Make sure its all there (we should see ppcross386, ppcrossx64)
which ppcrossx64
which ppcross386




Notes -

All this might be nonsense, I have not proof read it !


To install the necessary 32 bit libraries, we need to add  :i386 to package name

Issues with Linux32
Try a compile, its quite likely that the two windows modes will work fine but the Linux32 will fail at the linking stage, you must solve missing libraries and/or object files.  And its a mess ! Multiarch Ubuntu can transparently support both 32bit and 64bit code but there seems there is no agreement about where the necessary extra files live. So, lets deal with the packages first. Lazarus will tell you what its missing in its messages window. Your problem may be that the 32bit library is not installed, it may be installed somewhere where Lazarus is not looking or it maybe that the name Lazarus is checking for does not exist but the library is there all along.
So, a good start is to search for the name as mentioned in the lazarus error message, lets say the message mentions  "-lX11" (meaning the linked was passed X11 as a parameter to -l) -

find /usr -name "libX11*" <enter>
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
/usr/lib/i386-linux-gnu/libX11.so.6
/usr/lib/x86_64-linux-gnu/libX11.so
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
/usr/lib/x86_64-linux-gnu/libX11.so.6

Here (a few lines removed for clarity) we have two real libraries, one in gnu 32bit and one in the gnu 64bit directory. The remainders are symlinks (go ahead, try ls -l on them).  But while there is a symlink called  libX11.so in the 64bit dir, there is not one in the 32bit dir.  And that is what Lazarus is looking for.

ln  -s  /usr/lib/i386-linux-gnu/libX11.so.6   /usr/lib/i386-linux-gnu/libX11.so  <enter>

If there is no 32bit version showing up, install it -

sudo apt install libX11:i386 <enter>

Note the ':i386', thats how we tell it to get the 32bit version.

And, the third possibility, its there all along but Lazarus cannot see it, .....

NOTE: at this stage, I initially played with fpc.cfg, however, that now seems unnecessary, maybe it was a one off while generating the cross compiler ??  Anyway, in this block
# path to the gcclib,
#ifdef cpui386
-Fl/usr/lib/gcc/x86_64-linux-gnu/9/32
#endif

I had added -Fl/usr/lib32    and -FL/usr/lib/i386-linux-gnu   confirm later .....

just why this is necessary, I don't know, should Lazarus be searching for the various combinations or should Ubuntu install all possible links ?  In /usr/lib/x86_64-linux-gnu/libX11 for example, we have all possible links....

If you see messages about crtn.o (or crti.0) failure at linking stage,  first check where your 32bit versions of these files are.

find  /usr  -name crtn.o <enter>

They may well be in /usr/lib32 but apparently pointing a -Fl at them does not help (it seems other things, maybe ld itself, does really wants them in the gcc dir). Best thing to do is add a sym link from each to the gcc directory, its already mentioned in fpc.cfg. In my case, the gcc release is '9', your may well be anything from 7 to infinity. Use the one mentioned in your fpc.cfg file, fpcmakcfg knows what its doing.

ln -s /usr/lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/32/crti.o
ln -s /usr/lib32/crtn.o /usr/lib/gcc/x86_64-linux-gnu/9/32/crtn.o

[process_1]

Thank you Handoko and dbannon. I will try all...

But, one thing make me quite curious: why all that is not made inside process to remove packages, even a script publically available? I.e., if all upper care is required in order to remove  all residues from previous versions, as they are config files as well, symbolic links, environment variables etc, why not include that inside removable process?

If these scripts to install or upgrade probably read old config files and env. variables, then old ones are certainly necessary to be removed as well, even asking questions to remove each.

Specifically for DEB pakage as I do assume it is much better that all install/upgrade/remova process is done by package scripts, not to leave that to user/programmer.

That would probably be better also for tracking issues in scripts, since environment is clean for another installation.

And perhaps, a sticky thread "How to properly remove old versions for FPC and Lazarus" could be made here if not on wiki pages.

[dbannon]

I think the problem requiring "remove all" relates to mixing models.  Some one initially installs via a package manager, because its easy and reliable.  But they quickly come across some limitations of that model and make a few changes, "under the covers". And things become unpredictable.

In fact, that process I pointed you too is reasonably free of those sort of problems because it is, firstly self contained and secondly, because it puts the path to your new FPC install ahead of all others.  So, even if you have some manually created compiler lurking somewhere, you should get the recently installed one first so the historic one will be ignored.

If the package managers made a full cross compile package, maybe that would solve it. But, fact is, cross compiling is complicated and not needed by most users so, it does not happen.

The install we have talked about could be scripted but honestly, its really does not need it, you don't do it that often. And the script itself would have to take a lot of care to make sure everything happens as expected.  Everyones system is a bit different so, a little bit of doing and a lot of checking. By doing it by hand, you get to see and evaluate the result of each step, that way, as soon as something does not work, you can see what happened, adjust what you do and immediately edit the wiki page !

Davo

[PascalDragon]

system.ppu is phisically present here:
/usr/share/fpcsrc/3.2.0/rtl/units/x86_64-win64

Did you do a make crossinstall CPU_TARGET=x86_64 OS_TARGET=win64 INSTALL_PREFIX=/whatever?
Is that path entered in your fpc.cfg (either the global one in /etc/fpc.cfg or the global one in ~/.fpc.cfg)? It should be something like the following (assuming your INSTALL_PREFIX was indeed /whatever):

Code: [Select]

# searchpath for units and other system dependent things
-Fu/whatever/lib/fpc/$fpcversion/units/$fpctarget
-Fu/whatever/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/whatever/lib/fpc/$fpcversion/units/$fpctarget/rtl

You could also try to compile a simple example application on the command line and supply -vt to check where the compiler is looking for units, e.g.:

Code: [Select]

ppcrossx64 -Twin64 -vt helloworld.pas

[process_1]

Probably not the perfect cleaning, however after making and executing this script based on upper info but using DEB packages only, at least Win32 and Win64 cross-compillers compiled demo app without problems from lazarus.

Now, only left to find how to fix "Bad EXE format" when running 64-bit exe with wine...

[PascalDragon]

Now, only left to find how to fix "Bad EXE format" when running 64-bit exe with wine...

Is your wine set up correctly?

[dbannon]

Probably not the perfect cleaning, however after making and executing this script based on upper info but using DEB packages only, at least Win32 and Win64 cross-compillers compiled demo app without problems from lazarus.

Now, only left to find how to fix "Bad EXE format" when running 64-bit exe with wine...

OK, does that 64-bit exe work under windows ?  I personally have not had good experiences with Wine. If you are using it to test if something is OK, and it fails, you never really know if its a Wine problem or a 'something' problem.  Disclaimer, I have not used Wine for a very long time.

Davo

[process_1]

Well, I had to install dev. version of wine and wine64 from WineHQ. Simply there is some package dependeces and conflict issues on default repository.

At least it work for preliminary test on Linux, as I do not have any Windows machine for a long time now. Wine is far from ideal and many issues can be expected (which I had), but at least I can test briefly executable before I make installation file.

Windows seems to be free now (with some restrictions), but I simply do not need it anymore, nor I have spare space on HDD (nor other HDD) to install it.