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.
Regards,
Sergei
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
