Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Paul, On Sun, 2022-01-02 at 17:06 +0100, Paul Gevers wrote: > I'm not sure your allowed to run dpkg-reconfigure on a trigger as that > requires admin interaction. That sounds weird. As an admin I wouldn't > expect my configuration to get updated (when installing an "unrelated" > package). I just wanted to say that re-running dpkg-reconfigure did the trick. So we may be able to have a simpler script that regenerates the config file by running the required command and only that one. No need for a full reconfiguration, just un update of the path in /etc/fpc.cfg > And we would want to have a trigger on gcc upgrade? I don't > know how triggers work exactly, but wouldn't gcc need to provide the > trigger then? As far as I could see in [1], [2] and [3] we may be able to bypass gcc by triggering on /usr/lib/gcc or some of its sub folder. [1] https://wiki.debian.org/DpkgTriggers [2] https://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger [3] https://web.archive.org/web/20111022012105/http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/ -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi,
On 02-01-2022 14:29, Abou Al Montacir wrote:
If you check on a porter box for ARM or power PC, you will find only arm
or ppc related ifdefs.
So it works for all architectures, but not multiarch.
Isn't multiarch only properly working on some combinations anyways? E.g.
i386 can be multiarch on an amd64 capable computer. And armhf (and
sometimes armel) can be multiarch on (most) arm64 capable hosts? I
understood not all combinations currently (or ever) make sense.
I just checked the configuration on armhf and there wasn't a path to gcc
in the configuration. Shortly after I realized that's probably because
gcc wasn't installed. So while I checked armel, I installed gcc
alongside and after dpkg-reconfigure I got this on armel:
"""
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabi/11
#endif
"""
The cpuaarch64 bit part doesn't look correct, maybe that's because this
is inside an lxc on an arm64 host, so maybe the detection goes wrong.
And then on armel I got:
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabihf/11
#endif
On arm64
#ifdef cpuaarch64
-Fl/usr/lib/gcc/aarch64-linux-gnu/11
#endif
If we can safely suppose that all Debian architectures are using the
very same GCC version and path, then we can remove the ifdef and have a
generic path that works for mutiarch with a minimal effort.
But shouldn't the path depend on for which architecture your building?
However, it is true that if a new gcc version is installed after FPC
then the logic will fall down.
Can't we use a wildcard for the version number? I mean, after 11 comes
12 and 13 and ...
The wildcards work but only for one directory level. This means
/path/to/* and /path/to/prefix* will work, but not /path/to/*/* or
/path/to/prefix*/*
Ack.
If this is judged OK, I propose to close this ticket
As long as we have a new fpc in every Debian release, we're fine in
Debian, but e.g. Ubuntu users may experience issues when they carry the
same fpc over to a new version of Ubuntu that comes with a new gcc
version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure
fp-compiler-${VERSION} and get it updated.
I'm not sure your allowed to run dpkg-reconfigure on a trigger as that
requires admin interaction. That sounds weird. As an admin I wouldn't
expect my configuration to get updated (when installing an "unrelated"
package). And we would want to have a trigger on gcc upgrade? I don't
know how triggers work exactly, but wouldn't gcc need to provide the
trigger then?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Paul,
On Sun, 2022-01-02 at 08:19 +0100, Paul Gevers wrote:
> Hi,
>
> On 29-12-2021 23:47, Abou Al Montacir wrote:
> > So it should work correctly on all targets.
>
> Does this work correctly on all multiarch architectures too? I inspected
> only my own installation and there it only has cpui386 and cpux86_64.
If you check on a porter box for ARM or power PC, you will find only arm or ppc
related ifdefs.
So it works for all architectures, but not multiarch.
If we can safely suppose that all Debian architectures are using the very same
GCC version and path, then we can remove the ifdef and have a generic path that
works for mutiarch with a minimal effort.
>
> > However, it is true that if a new gcc version is installed after FPC
> > then the logic will fall down.
>
> Can't we use a wildcard for the version number? I mean, after 11 comes
> 12 and 13 and ...
The wildcards work but only for one directory level. This means /path/to/* and
/path/to/prefix* will work, but not /path/to/*/* or /path/to/prefix*/*
>
> > If this is judged OK, I propose to close this ticket
>
> As long as we have a new fpc in every Debian release, we're fine in
> Debian, but e.g. Ubuntu users may experience issues when they carry the
> same fpc over to a new version of Ubuntu that comes with a new gcc
> version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure fp-compiler-${VERSION}
and get it updated.
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi, On 29-12-2021 23:47, Abou Al Montacir wrote: So it should work correctly on all targets. Does this work correctly on all multiarch architectures too? I inspected only my own installation and there it only has cpui386 and cpux86_64. However, it is true that if a new gcc version is installed after FPC then the logic will fall down. Can't we use a wildcard for the version number? I mean, after 11 comes 12 and 13 and ... If this is judged OK, I propose to close this ticket As long as we have a new fpc in every Debian release, we're fine in Debian, but e.g. Ubuntu users may experience issues when they carry the same fpc over to a new version of Ubuntu that comes with a new gcc version. So I don't think it's nice. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#978040: [Pkg-pascal-devel] Bug#978040: Bug#978040: Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
I have just checked on a new installation of FPC 3.2.2 on ARM and it looks like the detection of GCC library path is correct. # path to the gcclib #ifdef cpuaarch64 -Fl/usr/lib/gcc/arm-linux-gnueabi/11 #endif The code, internally uses; gcc --print-libgcc-file-name So it should work correctly on all targets. However, it is true that if a new gcc version is installed after FPC then the logic will fall down. If this is judged OK, I propose to close this ticket -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Matija,
On Tue, 2020-12-29 at 18:50 +0100, Matija Nalis wrote:
> As for hard coding, those paths are ALREADY hard-coded at least forIntel
> architectures (amd64, i386), for example:
...
> That hard-coded paths seem to already be auto-generated on build somehow.
The file names /etc/fpc-${version}.cfg is generated automatically by postinst
script using fpcmkcfg tool that is shipped with the compiler.
So it is somewhat not hard coded, even if with time it will become wrong (for
example after a distupgrade)
> Note that current values also seem wrong if one is using multiarch /cross-
> compiling; as a path for "ifdef cpui386" should probably bedifferent than than
> the one for "ifdef cpux86_64".
Yes this is true, and is probably fixable by hacking in fpcmkcfg tool.
The fix should use variables recognized by the compiler (like $fpctarget) in
order to support correctly multi-arch.
I'll have a deeper look on that as it looks quite serious.
-- Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
On Tue, Dec 29, 2020 at 03:20:14PM +0100, Abou Al Montacir wrote: > Why gcc10 and not gcc8? I assume you are using sid.But then we need a way to > avoid hard coding the gcc version. Yes, gcc-10 is what build-essential installs on Sid (and Bullseye), which is what I am using there (as I'm trying to prepare my package using fpc for Bullseye). As for hard coding, those paths are ALREADY hard-coded at least for Intel architectures (amd64, i386), for example: - on amd64 Buster, /etc/fpc-3.0.4.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif - on i386 Sid, /etc/fpc-3.2.0.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif That hard-coded paths seem to already be auto-generated on build somehow. Note that current values also seem wrong if one is using multiarch / cross-compiling; as a path for "ifdef cpui386" should probably be different than than the one for "ifdef cpux86_64". I see two ways to fix this bug: - easier: Just remove the ifdefs, that is make that whole block just one line: -Fl/usr/lib/gcc/$TRIPLET/$GCC # whatever variable names are... eg. -Fl/usr/lib/gcc/i686-linux-gnu/10 # when generating binary package on i386 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 # when generating binary package on amd64 -Fl/usr/lib/gcc/arm-linux-gnueabi/10 # when generating binary package on armel etc. Then it will be behaving just it does now on amd64 and i386, but would also fix arm and other non-intel architectures - better (also fixing not just arm* builds, but multiarch too), but more work: Do not generate that block using variables, instead hard-code it manually for each Debian release and supported architectures from https://wiki.freepascal.org/Platform_defines, eg. #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 #endif #ifdef cpuarm -Fl/usr/lib/gcc/arm-linux-gnueabi/10 #endif #etc... While it needs more testing to find all the correct fpc ifdefs and gcc path triplets, it would fix all supported architectures, and make it more multiarch friendly (although there might be other multiarch blockers, I haven't checked) -- Opinions above are GNU-copylefted.
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Why gcc10 and not gcc8? I assume you are using sid.But then we need a way to avoid hard coding the gcc version. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Package: fpc Version: 3.2.0+dfsg-8 Severity: normal X-Debbugs-Cc: mnalis-debian...@voyager.hr Dear Maintainer, * What led up to the situation? trying to compile my source throws warnings (which subsequently causes failure to build due to "-Sewnh". I can of course remove that option and continue build even in presence of warnings, but would like to fix the problem at the source, as it is simple fix): fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO -O1 -gw -godwarfsets -gt -vewnhiq -Sa -Sy -vm4049 -Sewnh -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' -k-pie is.pas Hint: (11030) Start of reading config file /etc/fpc.cfg Hint: (11031) End of reading config file /etc/fpc.cfg Free Pascal Compiler version 3.2.0+dfsg-8 [2020/08/22] for arm Copyright (c) 1993-2020 by Florian Klaempfl and others (1002) Target OS: Linux for ARMHF (3104) Compiling is.pas (3104) Compiling _paths_.pas (9015) Linking is is.pas(86,1) Warning: (9034) "crtbeginS.o" not found, this will probably cause a linking failure is.pas(86,1) Warning: (9034) "crtendS.o" not found, this will probably cause a linking failure is.pas(86,1) Fatal: (10026) There were 2 errors compiling module, stopping Fatal: (1018) Compilation aborted Error: /usr/bin/ppcarm returned an error exitcode make: *** [Makefile:83: is] Error 1 * What exactly did you do (or not do) that was effective (or ineffective)? it seems that required /usr/lib/gcc/X/ library path is not included on fpc.cfg on ARM architectures (https://buildd.debian.org/status/package.php?p=ironseed shows that warnings at least for arm64, armel, armhf) It is mentioned in FAQ at https://wiki.lazarus.freepascal.org/Lazarus_Faq#I_receive_a_warning_during_the_linking_that_states:_Warning:_.22crtbeginS.o.22_.28or_.22crtendS.o.22.29_not_found and manually adding "-Fl/usr/lib/gcc/arm-linux-gnueabihf/10" to /etc/fpc-3.2.0.cfg fixes the problem. Similar library path is already present for amd64/i386 inside ifdef marked with "# path to the gcclib". It should be simple to add it to non-intel architectures too. * What was the outcome of this action? The two warnings show above appear (and so build fails due to '-Sewnh') * What outcome did you expect instead? No warnings, and sucessful build on ARM. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages fpc depends on: ii fp-docs-3.2.0 3.2.0+dfsg-8 ii fp-utils-3.2.0 3.2.0+dfsg-8 ii fpc-3.2.0 3.2.0+dfsg-8 fpc recommends no packages. fpc suggests no packages. -- no debconf information
