[Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Matija Nalis]

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.