Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Paul Gevers]

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.

"""
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabi/11
#endif
"""


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

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: 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.

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