[Pkg-pascal-devel] 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20220102/1cf997e2/attachment.sig>