[fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

Sergei Gorelkin sergei_gorelkin at mail.ru
Tue Jul 17 07:15:32 CEST 2012

17.07.2012 2:51, Jonas Maebe пишет:
> On 17 Jul 2012, at 00:36, Konstantin wrote:
>> 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 32 bit on a 64 bit Gentoo machine where the 32 bit
>> versions are in /usr/lib32/..... and linking fails due to invalid files.
>> So again my second question is, why are absolute paths used for
>> crtbegin.o, crti.o, crtend.o and crtn.o?
> Because based on the information provided to the compiler via command line parameters and the knowledge hardcoded into the compiler, those are the files that should be linked. Specifying their explicit path ensures that the linker will link the object files that compiler wants it to link, rather than some random files with the same names that the linker find somewhere else. Those files may be the wrong ones in your particular scenario, but most cases this strategy will prevent the exact opposite problem.
> What you can do is add something like this to the default configuration file on 64 bit hosts:
> #ifdef cpui386
> #ifdef linux
> # prevent searching the default library directories
> -Xd
> # add the 32 bit-specific library directories
> -Fl/usr/lib32
> -Fl/other/32bit/directory
> #endif
> #endif
> Patching the compiler source should not be necessary.
I'm afraid this isn't entirely correct. The problems arise when using "-n" in the command line (one 
example is compiling fpmake for packages directory). In this case any paths from fpc.cfg are 
ignored. Moreover, compiler silently ignores the absense of crti.o and company. The resulting 
executable manages to work somehow, but it is mostly by chance.


More information about the fpc-devel mailing list