Sergey Organov via fpc-devel
<fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org> writes:
> Jonas Maebe via fpc-devel
> <fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org> writes:
>
>> On 12/11/2021 20:33, Sergey Organov via fpc-devel wrote:
>>> Thanks, I believe I already do use -XR, here is entire compilation line:
>>> /opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/fpc/3.2.0/ppcrossarm -O3
>>> -CX -XX -Xs -veibq -vw-n-h- -MDelphiUnicode -Sg -Sc
>>> -XS -Tlinux -dCPU_ARM -Parm -CaEABIHF
>>> -XR/opt/cross/br/arm/armv7a/6.2.0.v6/usr/arm-javad-linux-gnueabihf/sysroot
>>> -XP/opt/cross/br/arm/armv7a/6.2.0.v6/usr/bin/arm-javad-linux-gnueabihf-
>>> -k-T/opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/ldscripts/armelf_linux_eabi.x
>>> -Fu/opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/fpc/3.2.0/units/arm-linux/*
>>> -Fl/opt/cross/br/arm/armv7a/6.2.0.v6/usr/arm-javad-linux-gnueabihf/sysroot/usr/lib/
>>> -Fu./src
>>> -Fu./generics.collections-master/src -Fu./lazutils -dJXT_PRCNTG
>>> -dJXTDB -dJXT_LNX -dJXT_RTPK -dCONSOLE
>>> -dSQLITE_LOAD_DYNAMICALLY -dCGGTTS -FU./build/arm-linux/obj/mkCGGTTS
>>> -o./build/arm-linux/bin/mkCGGTTS
>>> ./src/mkCGGTTS.pas
>>> and still I get all those warnings. Something's wrong with my
>>> command-line options?
>>
>> Does /opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/ldscripts/armelf_linux_eabi.x
>> perhaps contain any references to /usr/*?
>
> Wow, that's spot on! I've removed this offender and now everything is
> smooth. That option was inherited, and I didn't suspect it, as it used to
> work without warnings some time in the past, probably because of older
> binutils being in use at that time.
Ooops! I was too hasty getting at conclusions, sorry, and I was fooled
by my own hack to hide the annoying warning messages. Below is what I
actually found.
The root of the problem is that FPC cross implicitly reads /etc/fpc.cfg
configuration file, the latter having nothing to do with
cross-compilation.
Then, in the /etc/fpc.cfg file, among a lot of statements inappropriate
for cross-compilation (that happen to do no harm in my case), that is
only expected for the file that belongs to installed native compiler,
there is unconditional
-Fl/usr/lib/$fpctarget-*
directive that causes all this noise due to another bug, see below.
After the /usr/lib/$fpctarget-* read from /etc/fpc.cfg is translated by
FPC-cross to /usr/lib/arm-linux-* for my particular configuration of the
cross-compiler, it is *incorrectly* processed by the code handling
globbing of library paths to actually mean * in /usr/lib directory, and
then FPC happily globs this into tens of lines of
SEARCH_DIR("/usr/lib/xxx") statements in the link.res file that it
generates, and then, finally, it passes this messy link.res to GNU ld,
causing ld to produce tons of warnings.
A work-around here is to use -n option to prevent FPC from reading
/etc/fpc.cfg. Despite the existence of a work-around, the 3 things
probably worth fixing in the FPC source base are:
1. Globbing bug in TSearchPathList.AddLibraryPath() could likely affect
even native (as opposed to cross) compilations. The bug is that it
effectively silently translates /<path>/<anything>*<suffix> to
/<path>/*<suffix> for the purposes of globbing, while fpc.cfg definitely
assumes more reasonable behavior for globbing of /usr/lib/$fpctarget-*
specification.
2. When -XR is provided, the fpc.cfg should likely be searched for
relative to the sysroot, and /etc/fpc.cfg should never be implicitly
used by cross-compiler.
Further, even for a native compiler being installed, say, in /usr/local,
the fpc.cfg should probably be searched for in /usr/local/etc rather
than in /etc, so the policy of searching for fpc.cfg should probably be
revised in general.
3. This is unrelated to the issue, but worth to be mentioned anyway. For
whatever reason, -XR causes FPC to alter its strategy with respect to
creation of the link.res file, and instead of augmenting of what is
already there in GNU ld for given target, it entirely replaces GNU ld
idea of suitable linker script with some outdated version of one being
built-in into FPC. I failed to guess what's the reason for it, so I tend
to think it's a design mistake.
-- Sergey Organov
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
