Hello,

Using cross-compiler from x86-linux to arm-linux, I keep getting a lot of warnings at the linking stage of my programs, in the form:

/opt/[...]/arm-linux-gnueabihf-ld: warning: library search path "/usr/lib/eject/" is unsafe for cross-compilation /opt/[...]/arm-linux-gnueabihf-ld: warning: warning: library search path "/usr/lib/console-setup/" is unsafe for cross-compilation [...]

for virtually every sub-directory in /usr/lib. FPC 3.2.0 and 3.2.2 both have this issue.

This makes me suspect FPC cross produces instructions for the linker to search for files in wrong directories, where host libraries reside, that could lead to unpredictable results, and then tons of the warnings are really annoying.

What's the way to fix this?

Thanks,
-- Sergey Organov

Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit :

Try to use -Xd compiler option
~/bin$ fpc -h | grep -- -Xd
-Xd Do not search default library path (sometimes required for cross-compiling when not using -XR)

Pierre

Or better: use -XR/path/to/cross-root. -Xd is a hack that predates the introduction of -XR.

Jonas

Jonas Maebe via fpc-devel

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?

Thanks,
-- Sergey Organov

Does
/opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/ldscripts/armelf_linux_eabi.x perhaps contain any references to /usr/*?

Jonas

Jonas Maebe via fpc-devel

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.

Thanks a lot for your help!

Cheers,
-- Sergey Organov

Sergey Organov via fpc-devel

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

This one needs to become -Fl=/usr/lib/$fpctarget-* (see https://wiki.freepascal.org/User_Changes_3.2.0#Library_search_directories_and_custom_sysroots )

That indeed seems like a bug.

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.

The sysroot parameter only tells the compiler/linker where to look for system libraries and system object files. It is unrelated to the compiler's own configuration. The searched locations for configuration files is always the same (current directory, ~/.fpc.cfg, /etc/fpc.cfg).

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.

It is indeed possible to argue for this, but that would be a significant backward compatibility breakage and I'm not sure it would be worth it.

This has been fixed in trunk already. It was originally done that way because older versions of GNU LD did not support augmentation of built-in linker scripts, only replacing them wholesale. When we initially added support for GNU LD versions that did support augmentation, it was only implemented for native targets. Only more recently someone checked that it indeed also works correctly for cross-compiling and it was changed there as well.

Jonas

Jonas Maebe via fpc-devel

Yeah, I see. However, this file (/etc/fpc.cfg) is part of installation of particular version of FPC provided by corresponding Linux distribution, and is out of control of a person that installs custom (likely more recent) FPC. That's just yet another reason not to read /etc/fpc.cfg unless compiler is installed in /usr/, more so as different FPC versions may have incompatible ideas of its meaning.

[...]

Yep, backward compatibility could be an issue. A solution could be to still read /etc/fpc.cfg if /usr/local/etc/fpc.cfg is not found.

Ah, now I see, thanks for clarification!

-- Sergey Organov

Actually, even that would be wrong. I'm not sure where that comes from. It does not appear anywhere in our own sources. I think this may be a Debian addition.

Jonas

Jonas Maebe via fpc-devel

Could be. Anyway, it's rather old:

$ fpc | grep -i version
Free Pascal Compiler version 3.0.4+dfsg-23 [2019/11/25] for x86_64

-- Sergey Organov

Sergey Organov wrote

Jonas Maebe via fpc-devel writes:

.
.

.
.

Yep, backward compatibility could be an issue. A solution could be to still read /etc/fpc.cfg if /usr/local/etc/fpc.cfg is not found.

There are valid reasons for having a shared configuration for multiple installed versions of FPC (the one in /etc may equally serve for FPC installed into /usr/bin/ as well as /usr/local/ and other possible places), FPC provides means for specifying certain options conditionally there. In general, there's no particular reason why a person installing FPC should have rights for installation into /usr/local/ but not rights for changing configuration in /etc. If some person / user misses such rights, there's already the option of placing the configuration file into his or her home directory. Yes, /usr/local/etc/ might be added as one more location, but the more locations are supported, the bigger risk that users get confused due to multiple configuration files with different options specified.

Tomas

Tomas Hajny via fpc-devel

The compiler will still read only 2 configuration files at most, the default for given instance of the compiler, and user's one.

I.e., compiler installed in /usr should *not* read /usr/local/etc/fpc.cfg, only /etc/fpc.cfg. Compiler installed elsewhere, say, in /abc/def/custom, should read /abc/def/custom/etc/fpc.cfg.

The idea of backing to read /etc/fpc.cfg if /abc/def/custom/etc/fpc.cfg is not found for backward compatibility that I've suggested above now doesn't look useful to me, as I can't figure a use-case where it would help.

What is indeed confusing is sharing "system" configuration file between native and cross- compiler. I'd suggest that at least -XR (if not the installation directory itself) change the search path for configuration file.

Overall, it's up to you to decide what FPC does, but there are some agreements in the Linux world that FPC currently doesn't follow, and those agreements evolved out of practice as being convenient. For example, I currently have 3 different versions of Git installed, and each uses its own configuration:

1. In /usr, and it reads /etc/gitconfig
2. In /usr/local, and it reads /usr/local/etc/gitconfig
3. In $HOME/git, and it reads $HOME/git/etc/gitconfig

All of them read user $HOME/.gitconfig in addition, as well as project-specific configuration in .git/config.

As a user, I have write access to the 3-rd installation only (that I installed myself), and I have no problems using all these versions. It could have been useful if Git had support for site configuration common to all instances, but it's fine without such support as well, while FPC did surprise me with its behavior.

If you believe FPC should support some configuration that is common for all the instances of FPC installed on given machine (personally, I doubt it's that useful for compiler to bother), there probably should be separate support for the feature. E.g., having "include another config file" support in the config syntax could be enough for creating arbitrary flexible configurations, or one can check how, say, Emacs does this with its "default" and "site" configuration files.

-- Sergey Organov

.
.

The compiler will still read only 2 configuration files at most, the default for given instance of the compiler, and user's one.

The user would still need to remember that the first one depends on the installation path (which may not be even known to the compiler on some platforms as far as I remember!). The user may not even care/remember where the compiler is installed under normal conditions.

Why confusing? There is no "system" configuration file which would differ between native compilers and cross-compilers (note that cross-compilers may be installed at system-wide level, e.g. to /usr/bin/, equally to the native compiler!). There may indeed be a system-wide configuration file. Then there may be a user specific configuration file (~/.fpc.cfg on *nix machines) and a project specific configuration file (./fpc.cfg). Plus there may be a special configuration file for specific purpose which may be passed to the compiler using the '@' parameter. All of them allow specifying options valid for all cases / all compilations, as well as options used only under particular conditions (e.g. when compiling for a particular target, or a particular CPU). In addition, there are helpers which allow specifying certain configuration only once, but with certain parts changing value depending on the compilation target ($FPCTARGET). You can easily specify -XR valid for a particular target in your system-wide configuration file.

I'd suggest that at least -XR (if not the installation directory itself) change the search path for configuration file.

.
.

You should better read how the FPC option -XR is specified. What is the relation between 'Prepend <x> to all linker search paths' (see FPC help) and location of the configuration file?

Tomas

Tomas Hajny via fpc-devel

Yes, in which case everything is supposedly already configured by the administrator suitably.

Because it was not expected. I definitely can't point to any other user tool that, being installed in /opt/cross/bla-bla-bla/, would read configuration file from /etc/. Maybe I just didn't meet one yet. However, GCC, being most close to FPC by its application, definitely doesn't behave like that.

[...]

Currently? Apparently very little. Specifications sometimes change though.

Anyway, I'm not trying to insist on anything or trying to re-design configuration policy for FPC, just shared my feelings.

Thanks,
-- Sergey Organov

I think the GCC behaviour is at least partly because of historical reasons. GCC is often built as part of the sysroot itself, and originally didn't even have custom sysroot support and instead hardcoded all the paths in the binary. GCC is also often built without support for all target OSes, which means you could get compiler binary name conflicts.

FPC, OTOH, was designed from the start with as few differences as possible between native and cross-compiling. Our configuration files have macro support to deal with this, the compiler binaries by default always support all target OSes, and we have sysroot support (although we didn't have it from start, but initially we had hacks like the earlier mentioned -Xd in combination with -Fl).

As an aside, on e.g. macOS the -XR parameter is used to point FPC to a specific macOS SDK. As these are shipped by Apple, they (obviously) don't contain any FPC-specific files, configuration or otherwise.

Jonas

Jonas Maebe via fpc-devel

Fine, you've got your minds set already about it, and I've got my work-around in the form of -n option to get GCC-alike behavior, so everybody's happy!

I think you probably still need a fix for globbing of library paths though, at least maybe issue a warning or error, provided full-featured shell-like globbing is not feasible to implement.

Thanks,
-- Sergey Organov