Building FPC 3.2.2 on Debian "Testing" (Bookworm) x86_64

[MarkMLl]

I've been rebuilding my main system from Debian "Buster" to "Bookworm" since I need it to be pretty close to the bleeding edge for some stuff that I might need to build manually.

An existing FPC 3.2.2 runs OK on this, as does current Lazarus etc. and various application software built using it subject to a symlink issue I've mentioned elsewhere.

I can rebuild FPC 3.2.2 using 3.0.4 on a different system based on Debian 11 ("Bullseye") without problem.

If I try rebuilding 3.2.2 using 3.0.4 on the new system ("Bookworm") I get a failure, which appears to boil down to

Code: [Select]

>/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/linux$ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Cg -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dRELEASE  -Us -Sg system.pp
Segmentation fault

So far I've had no success trying to get a backtrace

Code: [Select]

>/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/linux$ gdb --args /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Cg -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dRELEASE  -Us -Sg system.pp
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1...
(gdb) run
Starting program: /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Cg -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dRELEASE -Us -Sg system.pp
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
No stack.
(gdb)

I'll try working through other versions on the same system, but think I'm out of my depth.

Later: on the "Bullseye" system I can build 2.6.4 using an existing 2.6.4. On the new "Bookworm" system that fails in a way similar to that described above. I assume intervening versions behave similarly.

MarkMLl

[MarkMLl]

Does anybody have any thoughts on this? Trying to look at it (with my very imperfect recollection of gdb) it appears that the problem is before I have any chance of setting a breakpoint etc.

Code: [Select]

>/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/linux$ gdb --args /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Cg -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dRELEASE  -Us -Sg system.pp

...

Reading symbols from /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1...
(gdb) starti
Starting program: /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Cg -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dRELEASE -Us -Sg system.pp
During startup program terminated with signal SIGSEGV, Segmentation fault.

MarkMLl

[Fred vS]

Hello Mark.

In my Bullseye system, I can build fpc 3.2.2, 3.2.3 and 3.3.1 with the "classical" script and fpc 3.2.0 or 3.2.2 compiler:

Code: Bash  [Select][+][-]

1. COMPILER=fpc
2. make clean
3. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
4. make FPC=$COMPILER install INSTALL_PREFIX=/usr/

But I did not try yet to build fpc 2.6.4. nor install last unstable Debian Bookworm.

Did you try to build fpc 3.2.2 using fpc 3.2.0 on Debian Bookworm?
Also do you have a idea of what difference between Bullseye vs Bookworm that could explain the fail of compilation?

[MarkMLl]

But I did not try yet to build fpc 2.6.4. nor install last unstable Debian Bookworm.

Did you try to build fpc 3.2.2 using fpc 3.2.0 on Debian Bookworm?
Also do you have a idea of what difference between Bullseye vs Bookworm that could explain the fail of compilation?

Bullseye is no problem at all, I can definitely build 3.2.2 and 2.6.4 so presume that the intervening versions are also OK.

The error as described was using 3.0.4 as the starting compiler, which I thought was SOP. If I switch to using 3.2.0 to build 3.2.2 things appear to progress further... I'll update this in a few minutes but want to post early in case anybody else is scratching their head.

MarkMLl

[Fred vS]

I'll update this in a few minutes but want to post early in case anybody else is scratching their head.

Ho, many thanks to be the explorer and save us a lot of hair, I will deeply study your result (and then maybe install Bookworm for testing).

[MarkMLl]

I can confirm that on Debian "Bookworm" x86_64 FPC 3.2.0 will build 3.2.2 successfully.

I'll try to sniff around this a bit more but my suspicion is that there's been a linker script change: remember the old -T warning that got removed?

It's a little unfortunate to have this inflection point, since by and large it's always been possible to build compiler versions forwards from the earliest supported on a given platform irrespective of the current OS (with the obvious exception of gtk version support etc., which mainly affects Lazarus).

On this specifica machine, I've leapfrogged directly from Buster to Bookworm bypassing Bullseye on my main development machine since I anticipate that it will either get a much-anticipated version of FreeCAD that fixes a grievous architectural bug, or that when the new FreeCAD is released it will be feasible to build it with the distro-supplied libraries.

So far it's been fairly painless (Quagga replaced by Bird, one symlink issue I've mentioned in another thread), but it's necessary first to install a minimal Bullseye and then upgrade in-situ. I find https://github.com/MarkMLl/installed-package-list to be a lifesaver, since if the log script is run routinely it's possible to generate a report of what packages have been installed manually and in what order.

MarkMLl

[dbannon]

............but it's necessary first to install a minimal Bullseye and then upgrade in-situ. ....

https://www.debian.org/devel/debian-installer/

Mark, the netinst CD size iso allow direct install of bookworm (or what ever Testing is at the time). You boot that iso, install a minimal Testing OS and then choose what else you want, DE, apps etc. Quite efficient as you only download what you need. On the other hand, inefficient if you are doing it repeatably (but thats what VMs are for).

And Testing now includes a functional if fractured FPC3.2.2 ....

Davo

[MarkMLl]

https://www.debian.org/devel/debian-installer/

Mark, the netinst CD size iso allow direct install of bookworm (or what ever Testing is at the time). You boot that iso, install a minimal Testing OS and then choose what else you want, DE, apps etc. Quite efficient as you only download what you need. On the other hand, inefficient if you are doing it repeatably (but thats what VMs are for).

No. As of three days ago a whole lot of kernel modules aren't in the installation image, and neither is software RAID which is a showstopper. Elsewhere on Debian's (somewhat diffuse) website it specified that the recommended way was starting off at Bullseye so that's what I did: I don't have infinite time to fossick around with this stuff and I really did want to get my system back ASAP to the point where it could run stuff which checks that the business servers are working properly.

MarkMLl

[MarkMLl]

I can confirm that on Debian "Bookworm" x86_64 FPC 3.2.0 will build 3.2.2 successfully.

I'll try to sniff around this a bit more but my suspicion is that there's been a linker script change: remember the old -T warning that got removed?

Attempting to build 3.2.2 without forcibly overriding the supported starting compiler version check.

Using:

3.2.2: "The only supported starting compiler version is 3.0.4. You are trying to build with 3.2.2.".

3.2.0: Builds OK (despite stricture above).

3.0.4: Fails as discussed at the start of this thread.

Attempting to build 3.2.0 without forcibly overriding the supported starting compiler version check.

Using:

3.2.0: Builds OK (even though it shouldn't).

3.0.4: Fails as discussed at the start of this thread.

So I think it's reasonable to assume that there's some change in 3.2.0 which improves its compatibility with the linker/loader used by Debian "Bookworm".

I've previously noted that

FPC 3.2.0 has a workaround for the longstanding -T warning message, which can be inhibited by the new -X9 option. Lazarus might have started to make assumptions (one way or the other) about FPC's linker behaviour, and about the precise binutils (i.e. ld etc.) version installed.

which was something that I think Jonas put me onto. I believe that documentation of that option was (intentionally) minimal, and don't know whether anything comparable would help with the Bookworm issue.

I'll leave it to those more familiar with the build process in general and Git in particular to try to throw more light on this; for the moment it's realistic for me to keep an older system running for build purposes or I could potentially use a VM or Docker.

MarkMLl

[dbannon]

.....
No. As of three days ago a whole lot of kernel modules aren't in the installation image, and neither is software RAID which is a showstopper. Elsewhere on Debian's (somewhat diffuse) website it specified that the recommended way was starting off at Bullseye so that's what I did: I don't have infinite time to fossick around with this stuff and I really did want to get my system back ASAP to the point where it could run stuff which checks that the business servers are working properly.

If you need those kernel moduals or RAID to boot, yep, that kills it but if the netinst iso can boot, everything else can be installed.

I am sure that  you can find, eventually, any recommendation you can imagine on the Debian Website. They do try and keep netinst CD size but its well under that right now so why its currently missing key components is anyone's guess.

I would not install Testing this early in the Debian cycle directly onto hardware with first putting it on a VM and looking at the stuff I am particularly interested in. But, of course, if that interesting stuff relates to underlying hardware, little choice.

Davo

[MarkMLl]

If you need those kernel moduals or RAID to boot, yep, that kills it but if the netinst iso can boot, everything else can be installed.

I am sure that  you can find, eventually, any recommendation you can imagine on the Debian Website. They do try and keep netinst CD size but its well under that right now so why its currently missing key components is anyone's guess.

With modules missing from the ISO and no network? And in the case of software RAID it was NOT SUPPORTED, i.e. not realistically fixable.

I would not install Testing this early in the Debian cycle directly onto hardware with first putting it on a VM and looking at the stuff I am particularly interested in. But, of course, if that interesting stuff relates to underlying hardware, little choice.

"Bullseye" is now more than a year old, so going by Debian's normal progression "Bookworm" has around a year left to release. It's "Testing", not "SID", and it's reasonable to use it on non-critical systems.

I'd also point out that VMs and in particular Docker can be problematic if e.g. a development system needs to get at arbitrary USB devices. The various VM schemes are fairly good, but non-VM containerisation has been casually mackled together using Linux's various namespace mechanisms and sundry hacks involving Netfilters etc. It's yet another illustration of how ill-conceived Linux really is, and how desperately the industry needs something better-architected.

MarkMLl

[MarkMLl]

which was something that I think Jonas put me onto. I believe that documentation of that option was (intentionally) minimal, and don't know whether anything comparable would help with the Bookworm issue.

As far as I can see, attempting to build 3.2.2 using 3.0.4 (doomed to failure) generates ppc1 using the line

Code: [Select]

/usr/bin/mkdir -p x86_64/units/x86_64-linux
/usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -V3.0.4 -O- -gl -Xs- -vt -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas
/usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
/usr/bin/mv -f ./pp ppcx64
...
/usr/bin/rm -f ppc1
/usr/bin/mv -f ppcx64 ppc1
make 'FPC=/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1' 'OLDFPC=' next CYCLELEVEL=2

while building 3.2.2 using 3.2.0 (shouldn't be allowed but works) generates ppc1 using the line

Code: [Select]

/usr/bin/mkdir -p x86_64/units/x86_64-linux
/usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -V3.2.0 -O- -gl -Xs- -vt -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas
/usr/bin/mv -f ./pp ppcx64
...
/usr/bin/rm -f ppc1
/usr/bin/mv -f ppcx64 ppc1
make 'FPC=/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1' 'OLDFPC=' next CYCLELEVEL=2

The commands are the same except for my attempt to override the compiler version with a -V (which doesn't work, but is at least useful for logging).

I think the problem is caused by the fix that went into 3.2.0 to eliminate the -T warning, which now appears to be required (rather than optional) for the linker being shipped by Debian.

I'd be interested if anybody could point me at the patch required, so that I can investigate whether it can be informally applied to older versions of FPC to make them compilable under Debian (on the assumption that Debian doesn't walk back from this change).

MarkMLl

[marcov]

(or test if it works with OPT=-O-

[MarkMLl]

(or test if it works with OPT=-O-

(Blinks and checks...) How do I force that in? My original command line is basically

Code: [Select]

make NO_GDB=1 OPT='-V3.0.4 -O- -gl -Xs-' all

so that -O2 is coming from some of the internal makefile gubbins.

MarkMLl

[marcov]

(from memory) Try adding RELEASE=0  or DEBUG=1 to the cmdline