Jonas Maebe via fpc-devel <fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org> writes:
> On 21/11/2021 20:51, Sergey Organov via fpc-devel wrote: >> 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. > > 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 > ) 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. [...] >> 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. 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. > >> 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. > > 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. Ah, now I see, thanks for clarification! -- Sergey Organov _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
