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

[Sergei Gorelkin]

On 17.07.2012 15:04, Jonas Maebe wrote:
>
> On 17 Jul 2012, at 07:15, Sergei Gorelkin wrote:
>
>> 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.
>
> Then you'd have to pass extra CROSSOPT parameters to the compiler when building (it's not that uncommon having to specify extra parameters when building a cross-distribution). Unless of course there is a specification somewhere in the LSB (or whatever it's called today) that specifies the default locations of cross-libraries on multi-arch systems, but we can keep adding code to the compiler to cater to all possible distributions.
>
I'm facing this problem even when not cross-compiling (and it is in fact unrelated to cross-compiling).
The issue is that the path to crti.o is known only to gcc, if it is installed in system. It isn't 
related to other libraries' path and it isn't known to ld. This path is queried by fpc install 
script and written to fpc.cfg. Later it can become invalid if gcc version is upgraded without 
reinstalling fpc (this is likely what happens at our test machines, see 
tests/packages/webtbs/tw14265 failing with "cannot find -lgcc").

I was thinking about quering this path at every ld invocation by running
`gcc -print-libgcc-file-name`, likewise it can be queried for cross-compiling with `gcc -m32 
-print-libgcc-file-name`. Hopefully doing so won't slow down much.
And probably fpc shouldn't keep silence if it needs gcc files to link and cannot find them.

Anyway, since currenly I'm working on ELF linker (reached the state when packages directory builds 
:-), I'll almost inevitably collect all linking-related issues

Regards,
Sergei