Re: [fpc-devel] Cross-compiling and warnings from linker
Jonas Maebe via fpc-devel writes: > On 23/11/2021 17:17, Sergey Organov via fpc-devel wrote: >> 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. > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
On 23/11/2021 17:17, Sergey Organov via fpc-devel wrote: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Tomas Hajny via fpc-devel writes: > On 2021-11-23 13:17, Sergey Organov via fpc-devel wrote: >> Tomas Hajny via fpc-devel >> writes: >> >>> On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: Jonas Maebe via fpc-devel writes: > . > . >> 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. Yes, in which case everything is supposedly already configured by the administrator suitably. > > >> 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. > > Why confusing? 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. [...] > >> 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 to all linker search paths' (see FPC > help) > and location of the configuration file? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
On 2021-11-23 13:17, Sergey Organov via fpc-devel wrote: Tomas Hajny via fpc-devel writes: On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: Jonas Maebe via fpc-devel writes: . . 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. 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. 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 to all linker search paths' (see FPC help) and location of the configuration file? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Tomas Hajny via fpc-devel writes: > On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: >> Jonas Maebe via fpc-devel >> writes: > . > . >> 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. > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: Jonas Maebe via fpc-devel writes: . . 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Jonas Maebe via fpc-devel writes: > On 22/11/2021 15:52, Jonas Maebe via fpc-devel wrote: >> 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 >> ) > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Jonas Maebe via fpc-devel 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
Re: [fpc-devel] Cross-compiling and warnings from linker
On 22/11/2021 15:52, Jonas Maebe via fpc-devel wrote: 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 ) 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
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 ) 1. Globbing bug in TSearchPathList.AddLibraryPath() could likely affect even native (as opposed to cross) compilations. The bug is that it effectively silently translates //* to //* for the purposes of globbing, while fpc.cfg definitely assumes more reasonable behavior for globbing of /usr/lib/$fpctarget-* specification. 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. 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. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Sergey Organov via fpc-devel
writes:
> Jonas Maebe via fpc-devel
> 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 //* to
//* 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
Re: [fpc-devel] Cross-compiling and warnings from linker
Jonas Maebe via fpc-devel 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. Thanks a lot for your help! Cheers, -- Sergey Organov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
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/*? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Jonas Maebe via fpc-devel writes: > On 2021-11-12 10:20, Pierre Muller via fpc-devel wrote: >> Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit : >>> 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? >> Try to use -Xd compiler option >> ~/bin$ fpc -h | grep -- -Xd >> -XdDo not search default library path (sometimes >> required for cross-compiling when not using -XR) > > Or better: use -XR/path/to/cross-root. -Xd is a hack that predates the > introduction of -XR. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
On 2021-11-12 10:20, Pierre Muller via fpc-devel wrote: Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit : 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? Try to use -Xd compiler option ~/bin$ fpc -h | grep -- -Xd -XdDo not search default library path (sometimes required for cross-compiling when not using -XR) Or better: use -XR/path/to/cross-root. -Xd is a hack that predates the introduction of -XR. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross-compiling and warnings from linker
Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit : 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? Try to use -Xd compiler option ~/bin$ fpc -h | grep -- -Xd -XdDo not search default library path (sometimes required for cross-compiling when not using -XR) Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Cross-compiling and warnings from linker
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
