crosscompile 64/32 crti.o etc

[tharmo]

After several days of desparation I did I finally managed to get a first hello world to compile for 32-bit linux on my 64-bit lazarus. I'm still not in the dry yet. and other seem to have similar problems, so here goes.

Everything kept stopping at "cannot find crtl.o". Trying to "sudo apt-get install libsvga1-dev" etc. ran into dependency problems. Finally found someone suggesting "sudo apt-get install libsvga1 libsvga1-dev" (I had tried the two separately several times). After that I could run "sudo apt-get install gcc-multilib", and suddenly I had the much longed for crtl.o in /usr/lib32.

Fpc (or linker.. whatever) does not still find it. To be able to link I have to copy the crtl.* files temporarily from usr/lib32 to /usr/lib/
I have tried to instruct fpc in fpc.cfg to look in /usr/lib32, but it insist on looking at /usr/lib

Now I'm just wondering what would have been the correct way to get cross-compilation to work, given the problem with ctrl.o? I tried to follow the instructions in http://wiki.lazarus.freepascal.org/Installing_Lazarus to make a clean new install, and in http://wiki.lazarus.freepascal.org/Cross_compiling , but apparently something went wrong and I found myself considerably contributing to global warming for all the gowgling I had to do to get this far.

[marcov]

Also see the earlier thread:

http://www.lazarus.freepascal.org/index.php/topic,15557.0.html

If I understood correctly, the problem is the linker.  A summary of my conclusions:

1. Linkers have a path (prefix) internally where they look first. Normal linkers have /usr (and they append "lib" to that), and crosslinkers have a different path internally. (usually some dummy path on the system the binlinkers were generated)
2. On (Linux) biarch systems (systems that are 32/64-bit) there is one linker that handles everything, and is switchable between 32-bit and 64-bit using a parameter (which FPC supports)
3. However, the linker doesn't seem to change the path if the 32-bit mode is selected. (to use /usr/lib32 instead of /usr/lib)
4. This doesn't turn up with GCC, because GCC only passes absolute paths to the linker. (IOW it does searching itself).

Possible solutions, in decreasing preference.
1. Report a bug with your distro or GNU, and have them fix the biarch situation. If they use alternative paths for different architectures, the distribution shipped linker should respect that.
2. Change FPC to the GCC model. I think FPC should at least have an option to search everything itself in the case of defective linkers. The trouble is that this is a long term solution.
3. Use the workaround luke!

The (untested, theory only) workaround is based on the fact that there is a linker parameter that overrides the internal prefix. But it wants to look in lib always (-XR), so we give it a lib.

a. Make a new directory  say /usr/exp   This is going to be our new prefix. Make its owners and permissions the same as /usr
b. Symlink /usr/exp/lib to point to /usr/lib32
c. Pass -XR/usr/exp to FPC, or put it in your fpc.cfg under #ifdef i386

Problems:
- still untested, based on certain workarounds I used for linux crosscompiling.
- might make the binaries dependent on the system it was build (use -Xr to fix that?)

Note, if you want to test this, start on the cmdline with FPC first, and only then go to Lazarus.

[tharmo]

After upgrade to ubuntu 11.10 cross-compilation stopped working. After some reinstalls ála
http://askubuntu.com/questions/69119/linking-problems-after-updating-to-11-10
and lazarus:"environment - rescan fpc-source", and lazarus:"tools -build lazarus"
I'm down to one error:  /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o when searching for /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o

I believe I would need something like
/usr/lib/gcc/i386-linux-gnu, but I cannot figure out where to find such a beast. (I do have an  /usr/lib/gcc/i686-linux-gnu, but it is empty). Any ideas?
 -Timo

[Ocye]

I don't know what you did with "some reinstalls". But it sounds very strange.
As marcov wrote the linker is to blame for that issue. Because you cannot pass the lib32 path correctly it wouldn't work even with a good multiarch setup. I "solved" the problem with a virtual machine running a tiny 32bit OS.

[tharmo]

"some reinstalls" refers to the ones suggested at http://askubuntu.com/questions/69119/linking-problems-after-updating-to-11-10 (shuttle87 answer). And the problems seems to be different from the previous one, instead of the files being there but not found by the linker, it seems that there is no correct crtbegin.o anywhere. I realize an ubuntu forum would be the right place to ask this, and am gathering my strengt to do that (any hints about what forum to ask in, and what info is required is appreciated).

>I "solved" the problem with a virtual machine running a tiny 32bit OS.

I had it "solved" by the dirty hack of temporarily replacing files in /usr/lib, but it is not enough after the upgrade.

I'm dreaming of someone setting up a web service that would do cross-compilations on uploaded files. (the "someone" could be partly me, but  I fear my skills are not quite up to what it would take).

[marcov]

Please reread my post. It contains a way to circumvent the problems based on FPC source inspection, by creating a prefix that contains a "lib" directory, like the linker wants.

It might not work the first time (requiring additional symlinks), but please try, so that we can devise a workaround for this recurring problem

[tharmo]

>Please reread my post.
Ok. Started doing that. I started by

sudo mkdir usr/exp
sudo chmod --reference=usr usr/exp
sudo ln -s /usr/lib32 /usr/exp/lib
fpc -vt bogus  (to find fpc.cfg)

the fpc-bogus line revealed that I had some outdated references. I changed in #ifdef cpui386

#-Fl/usr/lib32/gcc/I686-linux-gnu/4.5.2

to

-Fl/usr/lib32/gcc/I686-linux-gnu/4.5.4

  (and a similar change in #ifdef cpux86_64 section).

Now crosscompling works without any tricks. I did not "Pass -XR/usr/exp".

I don't know how to see which files the linker is using, but apparently something that works.  Perhaps I had some similar errors previously, or perhaps something has been fixed with ubuntu updates.

[Ocye]

I changed in #ifdef cpui386

#-Fl/usr/lib32/gcc/I686-linux-gnu/4.5.2

to

-Fl/usr/lib32/gcc/I686-linux-gnu/4.5.4

  (and a similar change in #ifdef cpux86_64 section).

So that was be the reason why *.o were not found. 
You don't need marcov's compiler switch magic anymore, so it's not important to know which libs are used. The question was, as far as I understand, whether the executable uses /usr/exp or system standard. To check these dependencies the tool ldd would help.