<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello!<br>
<br>
Free Pascal has been designed to run on several platforms on many
architectures which is a neat feature. The executable name is chosen
accordingly - ppc386, ppcx64 etc. to be able to have many at the
same time on the same system. When building from source it
automatically detects the platform on which it is running.
Unfortunately, when building on amd64 you end up with the ppcx64
compiler which can not compile for x86 targets.<br>
<br>
I'm using Free Pascal on Gentoo so I created ebuilds (<a
href="https://bugs.gentoo.org/show_bug.cgi?id=322971">see Gentoo
bug report here</a>) to compile FPC on amd64 machines for x86 as
well if desired. Currently this involves compiling everything twice
and then install it together. This way the advantage of the CPU to
be able to run code in 32 bit and 64 bit on the same system can be
used.<br>
<br>
So first question, is there a better way instead of compiling
everything twice? Maybe something can be reused?<br>
<br>
The second issue is more troublesome. In
compiler/systems/t_linux.pas the function
TLinkerLinux.WriteResponseFile generates a linker response file
where it gives absolute paths of crtbegin.o, crti.o, crtend.o and
crtn.o. The bad thing is that these paths are determined by the FPC
function librarysearchpath.FindFile and as this function does not
honor the target architecture. It always returns /usr/lib/..... as
the default architecture version of these files is located there.
This of course fails when compiling x86 on amd64 Gentoo machine
where the 32 bit versions are in /usr/lib32/..... and linking fails
due to invalid files.<br>
<br>
So second question is, why are absolute paths used for crtbegin.o,
crti.o, crtend.o and crtn.o? When no paths are specified the linker
automatically chooses the right version and everything it seems to
be OK.<br>
<br>
I made a patch for this (see the link to the ebuild above) to
specify the object files without paths and on Gentoo it is running
fine for me quite a while now. I can develop the 32 bit software on
any of my machines and it does not matter if I'm running 32 or 64
bit. Anyway, it would be a nice feature to have it included in
official source and Gentoo devs would like to know from upstream
what the "right" solution for this linking issue is. You are welcome
to add comments to the Gentoo bug report above.<br>
<br>
Have fun,<br>
Konstantin<br>
</body>
</html>