Building FPC 3.2.2 on Debian "Testing" (Bookworm) x86_64 lazarus / 64-FPC development ---------------------------------------------------------------------- MarkMLl · 2022-10-24 09:08 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 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: . Find the GDB manual and other documentation resources online at:     . 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 · 2022-10-25 09:06 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 · 2022-10-25 10:05 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i COMPILER=fpcmake cleanmake all FPC=$COMPILER OPT="-Fl/usr/local/lib" 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 · 2022-10-25 10:31 Quote from: Fred vS on October 25, 2022, 12:05:07 pmBut 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 · 2022-10-25 10:42 Quote from: MarkMLl on October 25, 2022, 12:31:27 pmI'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 · 2022-10-25 11:05 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 · 2022-10-25 11:39 Quote from: MarkMLl on October 25, 2022, 01:05:47 pm............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 · 2022-10-25 12:02 Quote from: dbannon on October 25, 2022, 01:39:28 pmhttps://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 · 2022-10-25 14:50 Quote from: MarkMLl on October 25, 2022, 01:05:47 pmI 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 QuoteFPC 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 · 2022-10-25 22:23 Quote from: MarkMLl on October 25, 2022, 02:02:49 pm..... 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 · 2022-10-26 07:11 Quote from: dbannon on October 26, 2022, 12:23:28 amIf 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. QuoteI 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 · 2022-10-26 08:52 Quote from: MarkMLl on October 25, 2022, 04:50:44 pmwhich 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 · 2022-10-26 08:56 (or test if it works with OPT=-O- ---------------------------------------------------------------------- MarkMLl · 2022-10-26 09:12 Quote from: marcov on October 26, 2022, 10:56:28 am(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 · 2022-10-26 09:43 (from memory) Try adding RELEASE=0  or DEBUG=1 to the cmdline ---------------------------------------------------------------------- MarkMLl · 2022-10-26 09:53 Just tried with Code: [Select]make NO_GDB=1 DEBUG=1 OPT='-V3.0.4 -O- -gl -Xs-' all which ran through to the same place Code: [Select]/usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/compiler/ppc1 -Ur -gl -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- -dx86_64 -dDEBUG -dRELEASE  -Us -Sg system.pp ...noting the -d in that. Have to go out for a while, continued suggestions appreciated. MarkMLl ---------------------------------------------------------------------- TRon · 2023-01-21 10:12 Sorry, I hope you do not mind MarkMLI but I have opted to bump this thread instead of creating a new one as it seemed fitted to me (if that is a problem then please let me know and I'll move and delete this post). My experience with building FPC (from source, using official distributed startup compiler) on debian bookworm. Note that building 3.2.2 with 3.2.0 as start compiler works as well as building all of the mentioned versions on a debian buster system. build="3.2.0" start="3.0.4" OPT="-O-"  (segfault msgtxt.inc) Code: [Select]make -C utils cleanall make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler/utils' /usr/bin/rm -f fpc ppufiles ppudump ppumove mka64ins mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o mka64ins.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmka64ins.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmka64ins.a libimpmkarmins.a libimpmkx86ins.a /usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu /usr/bin/rm -rf units /usr/bin/rm -rf bin /usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh ppas.sh ppaslink.sh make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler/utils' /usr/bin/rm -rf x86_64/units /usr/bin/rm -rf x86_64/bin /usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl /usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcppc x86_64/ppcsparc x86_64/ppcarm x86_64/ppcarmeb x86_64/ppcx64 x86_64/ppcppc64 x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcavr x86_64/ppcjvm x86_64/ppc8086 x86_64/ppca64 x86_64/ppcsparc64 /usr/bin/rm -f ppcx64 /usr/bin/mkdir -p x86_64/units/x86_64-linux make ./msg2inc make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' /media/ramdisk-8gb/capture/bin/bootstrap/ppcx64-3.0.4 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/media/ramdisk-8gb/capture/src/fpc-3.2.0/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -O- -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' ./msg2inc msg/errore.msg msg msg make[5]: *** [Makefile:4188: msgtxt.inc] Segmentation fault make[5]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' make[4]: *** [Makefile:4309: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' make[3]: *** [Makefile:4313: ppc1] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' make[2]: *** [Makefile:4325: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0/compiler' make[1]: *** [Makefile:2799: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.2.0' make: *** [Makefile:2831: build-stamp.x86_64-linux] Error 2 build="3.0.4" start="3.0.2" OPT="-O-"  (segfault msgtxt.inc) Code: [Select]make -C utils cleanall make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler/utils' /usr/bin/rm -f fpc ppufiles ppudump ppumove mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmkarmins.a libimpmkx86ins.a /usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu /usr/bin/rm -rf units /usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler/utils' /usr/bin/rm -rf x86_64/units /usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl /usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcx64 x86_64/ppcppc x86_64/ppcsparc x86_64/ppcppc64 x86_64/ppcarm x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcjvm x86_64/ppc8086 x86_64/ppcx64 /usr/bin/rm -f ppcx64 /usr/bin/mkdir -p x86_64/units/x86_64-linux make ./msg2inc make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' /media/ramdisk-8gb/capture/bin/bootstrap/ppcx64-3.0.2 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/media/ramdisk-8gb/capture/src/fpc-3.0.4/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -O- -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' ./msg2inc msg/errore.msg msg msg make[5]: *** [Makefile:3858: msgtxt.inc] Segmentation fault make[5]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' make[4]: *** [Makefile:3971: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' make[3]: *** [Makefile:3975: ppc1] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' make[2]: *** [Makefile:3987: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4/compiler' make[1]: *** [Makefile:2780: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.4' make: *** [Makefile:2812: build-stamp.x86_64-linux] Error 2 build="3.0.2" start="3.0.0" OPT="-O-" (segfault msgtxt.inc) Code: [Select]make -C utils cleanall make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler/utils' /usr/bin/rm -f fpc ppufiles ppudump ppumove mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmkarmins.a libimpmkx86ins.a /usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu /usr/bin/rm -rf units /usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler/utils' /usr/bin/rm -rf x86_64/units /usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl /usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcx64 x86_64/ppcppc x86_64/ppcsparc x86_64/ppcppc64 x86_64/ppcarm x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcjvm x86_64/ppc8086 x86_64/ppcx64 /usr/bin/rm -f ppcx64 /usr/bin/mkdir -p x86_64/units/x86_64-linux make ./msg2inc make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' /media/ramdisk-8gb/capture/bin/bootstrap/ppcx64-3.0.0 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/media/ramdisk-8gb/capture/src/fpc-3.0.2/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -O- -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' ./msg2inc msg/errore.msg msg msg make[5]: *** [Makefile:3855: msgtxt.inc] Segmentation fault make[5]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' make[4]: *** [Makefile:3968: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' make[3]: *** [Makefile:3972: ppc1] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' make[2]: *** [Makefile:3984: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2/compiler' make[1]: *** [Makefile:2779: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.2' make: *** [Makefile:2811: build-stamp.x86_64-linux] Error 2 build="3.0.0" start="2.6.4" OPT="-O-" (segfault system.ppu) Code: [Select]make -C /media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl 'OPT=-O-' all make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl' make -C linux all make[7]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/linux' as --64 -o /media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/units/x86_64-linux/prt0.o x86_64/prt0.as as --64  -o /media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/units/x86_64- linux/dllprt0.o x86_64/dllprt0.as as --64 -o /media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/units/x86_64- linux/cprt0.o x86_64/cprt0.as as --64 -o /media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/units/x86_64- linux/gprt0.o x86_64/gprt0.as /media/ramdisk-8gb/capture/src/fpc-3.0.0/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/units/x86_64-linux -Cg -O- -dx86_64 -dRELEASE -Us -Sg system.pp make[7]: *** [Makefile:3489: system.ppu] Segmentation fault make[7]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl/linux' make[6]: *** [Makefile:1928: linux_all] Error 2 make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/rtl' make[5]: *** [Makefile:4076: rtl] Error 2 make[5]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/compiler' make[4]: *** [Makefile:3967: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/compiler' make[3]: *** [Makefile:3976: ppc2] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/compiler' make[2]: *** [Makefile:3984: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0/compiler' make[1]: *** [Makefile:2780: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-3.0.0' make: *** [Makefile:2812: build-stamp.x86_64-linux] Error 2 build="2.6.4" start="2.6.2" OPT="-O-" (segfault system.ppu) Code: [Select]make -C /media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl 'OPT=-O-' all make[6]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl' make -C linux all make[7]: Entering directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/linux' as --64 -o /media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/units/x86_64-linux/prt0.o x86_64/prt0.as as --64 -o /media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/units/x86_64- linux/dllprt0.o x86_64/dllprt0.as as --64 -o /media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/units/x86_64- linux/cprt0.o x86_64/cprt0.as as --64 -o /media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/units/x86_64- linux/gprt0.o x86_64/gprt0.as /media/ramdisk-8gb/capture/src/fpc-2.6.4/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/units/x86_64-linux -Cg -O- -dx86_64 -dRELEASE -Us -Sg system.pp make[7]: *** [Makefile:3055: system.ppu] Segmentation fault make[7]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl/linux' make[6]: *** [Makefile:1754: linux_all] Error 2 make[6]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/rtl' make[5]: *** [Makefile:3587: rtl] Error 2 make[5]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/compiler' make[4]: *** [Makefile:3488: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/compiler' make[3]: *** [Makefile:3497: ppc2] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/compiler' make[2]: *** [Makefile:3505: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4/compiler' make[1]: *** [Makefile:2516: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/capture/src/fpc-2.6.4' make: *** [Makefile:2526: build-stamp.x86_64-linux] Error 2 I assume that the rest (e.g. older versions) follow the same pattern in segfaulting on system.ppu I have not been able to figure out the culprit. And yes, I am in need of some of those old compilers (as well). ---------------------------------------------------------------------- MarkMLl · 2023-01-21 11:33 I think the important thing is that if the host computer is Debian "Bookworm" x86_64, it's not possible to progress from 3.0 to 3.2. This build did work on older systems. When I spotted it I was wondering whether it was related to something similar on SPARC that I came across a year or so ago, which somebody (Jonas?) helped me out with by mentioning a target-specific option related to the fix in FPC related to the old linker -T warning. I believe that it's distinct from the issue I mentioned earlier where versions of FPC older than 3.2.2 won't build programs referencing the C libraries (cthreads etc.) on Bookworm where they were find on older Debian versions. Sorry if this is excessively concise, we seem to be having power cuts... MarkMLl ---------------------------------------------------------------------- Thaddy · 2023-01-21 11:40 Quote from: MarkMLl on January 21, 2023, 12:33:27 pmI think the important thing is that if the host computer is Debian "Bookworm" x86_64, it's not possible to progress from 3.0 to 3.2. This build did work on older systems. It works a bit different: the bootstrap compiler is always the previous release version, and the only documented bootstrap compiler, but there is sometimes a grace period allowed if, and only if, compiler changes would still allow a bootstrap with an older version. In such cases the grace period is removed somewhat later. As such this can greatly vary between updates. After a previous version is updated in such a way that the new compiler relies on new features introduced in the bootstrap version, this is not possible. Hence sometimes an older version can be used as a bootstrap compiler, and sometimes not and this can vary per release. So the statement that it "worked in the past" is false: that is and has always been dependent per release. Note that the other way around is also possible. There is a make parameter called OVERRIDEVERSIONCHECK=1. You might assume that you can then build with another version, both older or the same as the newests release. Alas, the same as above: it is possible that the newest version relies on features from the previous stable release, so you can not bootstrap the latest release with itself because some features may have disappeared or changed in implementation (the breaking changes) Unless you pretend to know what you are doing only the adagium "the bootstrap compiler is always the previous release version" holds. BTW: the build scripts always can tell which version(s) are allowed for your particular bootstrap. So, I hope it is clear it has nothing to do with "previous versions" ---------------------------------------------------------------------- MarkMLl · 2023-01-21 12:45 In the 3.2.2 makefile, REQUIREDVERSION is set to 3.0.4. And that worked correctly with older versions of Debian. MarkMLl ---------------------------------------------------------------------- Thaddy · 2023-01-21 13:04 About the required version on Debian: That *may* be an error. I expect 3.2.0. Note I submitted patches for such occurances in the past. Right now I am unable to check it, but it should be 3.2.0. 3.2.2. is built with 3.2.0. Current Debian installs also 3.2.0, btw. It may very well be that the deb in the debian repo is packaged with a wrong version. It was a mess. And https://wiki.freepascal.org/User_Changes_3.2.0 has some nice "things" that may be breaking changes from 3.0.4. and so 3.0.4. can't ever build 3.2.2. from the looks of it. ---------------------------------------------------------------------- marcov · 2023-01-21 13:23 Quote from: MarkMLl on January 21, 2023, 01:45:29 pmIn the 3.2.2 makefile, REQUIREDVERSION is set to 3.0.4. Probably that is an own debian hack. In SVN of the 3.2.2 release branch it is not: https://gitlab.com/freepascal.org/fpc/source/- /blob/release_3_2_2/Makefile.fpc If I look at TRon's last post, it seems that binaries generated with obsolete versions of FPC are not compatible with something in the future debian. If those binaries are still needd (e.g. for some debian internal bootstrap) , maybe the easiest solution is notify Debian, and get that fixed. ---------------------------------------------------------------------- Thaddy · 2023-01-21 13:25 Tnx for confirming. That's what I suspected. ---------------------------------------------------------------------- MarkMLl · 2023-01-21 13:34 Quote from: Thaddy on January 21, 2023, 02:04:33 pmAbout the required version on Debian: That *may* be an error. I expect 3.2.0. ... And https://wiki.freepascal.org/User_Changes_3.2.0 has some nice "things" that may be breaking changes from 3.0.4. and so 3.0.4. can't ever build 3.2.2. from the looks of it. 3.0.4 certainly built 3.2.2 on the previous version of Debian I used. Otherwise that wouldn't have been the one I started with on "Bookworm". The rule I understood and have always worked to, for native builds on various platforms from somewhere around 2.2, was that the current compiler should be built with the latest patch of the previous minor version. When I raised this a few months ago I was given the impression- although I concede that I might have read it wrong- that I should have been using 3.2.0 to build 3.2.2 and that since 3.0.4 was obsolete the developers... well, didn't give a damn frankly. Now I'd point out that there does appear to be provision for a fallback to 3.2.0 in 3.2.2's makefile. But in that case I'd expect something a bit more useful, at least in terms of error message. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2023-01-21 13:46 Quote from: marcov on January 21, 2023, 02:23:18 pmQuote from: MarkMLl on January 21, 2023, 01:45:29 pmIn the 3.2.2 makefile, REQUIREDVERSION is set to 3.0.4. Probably that is an own debian hack. In SVN of the 3.2.2 release branch it is not: NO EFFING WAY!!!!!!!!!!!!!!!!!!!! Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ mkdir scratch$ cd scratch$ sha1sum ../fpcbuild-3.2.2.tar.gz41f8783595907ae5f56b58b909707af15a460de6  ../fpcbuild-3.2.2.tar.gz$ tar xzf ../fpcbuild-3.2.2.tar.gz$ grep REQUIREDVERSION fpcbuild- 3.2.2/fpcsrc/MakefileREQUIREDVERSION=3.0.4REQUIREDVERSION2=3.2.0ifneq ($(FPC_VERSION),$(REQUIREDVERSION))ifneq ($(FPC_VERSION),$(REQUIREDVERSION2))        $(error The only supported starting compiler version is $(REQUIREDVERSION). You are trying to build with $(FPC_VERSION).)$ MarkMLl ---------------------------------------------------------------------- Thaddy · 2023-01-21 13:55 What you showed is the tempory grace I referred to. Also note the Debian version is a patched version and that patch did not come from the core fpc developers.... ---------------------------------------------------------------------- MarkMLl · 2023-01-21 14:01 Quote from: Thaddy on January 21, 2023, 02:55:55 pmWhat you showed is the tempory grace I referred to. Also note the Debian version is a patched version and that patch did not come from the core fpc developers.... I AM NOT USING THE DEBIAN VERSION!!!!!!!!!!!!!!!!! And what is more, I am talking about a binary version of 3.0.4 plus a source version of 3.2.2 moved TOGETHER from one Debian release to another, so "grace period" or whatever you want to call it is quite simply bullshit. ---------------------------------------------------------------------- marcov · 2023-01-21 14:08 That is the SHA1SUM from the website also. I just noticed that that update is an year ago (IOW after the release). Thaddy is right though, officially only the previous working release (so 3.2.0 for 3.2.2) is supported, even if for some reason (and/or target) an older version is not explicitly forbidden. The REQUIRE* is a simple safeguard to avoid accidental building with ancient versions. It is not in any case a guarantee. If debian delivers with 3.0.4, that is against official FPC policy, and thus on their head. ---------------------------------------------------------------------- Thaddy · 2023-01-21 14:10 Grace period solved I guess? Tnks Marco. ---------------------------------------------------------------------- MarkMLl · 2023-01-21 14:29 Quote from: marcov on January 21, 2023, 03:08:24 pmIf debian delivers with 3.0.4, that is against official FPC policy, and thus on their head. Marco. I have never touched any Debian-supplied versions of FPC. I'm not even certain that Debian packaged FPC when I started using it. This is ENTIRELY about 3.0.4 built from source, and its inability to build 3.2.2 on one particular platform. That should have worked. Or if it didn't work, it should have provided some sensible error message. Or if there wasn't a sensible error message, I'd expect some sort of acknowledgement of that from the developers. MarkMLl ---------------------------------------------------------------------- marcov · 2023-01-21 14:47 Quote from: MarkMLl on January 21, 2023, 03:29:48 pmThis is ENTIRELY about 3.0.4 built from source, and its inability to build 3.2.2 on one particular platform. That should have worked. No it SHOULDN'T, only the previous version (i.e 3.2.0) is a guarantee, and even that is sometimes doubtful for some new targets (requiring cross compilation to bootstrap). The second required version (3.0.4 in this case)  in the makefile is only there to ease the release process (when the supported compiler changes) and for certain targets that skipped the previous release or where it was defunct somehow. It is BY NO MEANS A GUARANTEE. QuoteOr if it didn't work, it should have provided some sensible error message. We can't retroactively change a released and obsolete 3.0.4 to create proper error messages. ---------------------------------------------------------------------- MarkMLl · 2023-01-21 15:06 Nobody is saying you need to fix 3.0.4. You need to find what in 3.2.x is being broken by the latest Debian. Look, I've been a committed FPC user for what- 15 years or so?- but this is testing my patience to the limit. You need to step back and consider how it would look to a potential new user: whether a refugee from Delphi, or somebody who's never touched Pascal before. MarkMLl ---------------------------------------------------------------------- marcov · 2023-01-21 15:12 Quote from: MarkMLl on January 21, 2023, 04:06:50 pmNobody is saying you need to fix 3.0.4. You need to find what in 3.2.x is being broken by the latest Debian. It isn't apparently as you say yourself: QuoteI can confirm that on Debian "Bookworm" x86_64 FPC 3.2.0 will build 3.2.2 successfully. QuoteLook, I've been a committed FPC user for what- 15 years or so?- but this is testing my patience to the limit. You need to step back and consider how it would look to a potential new user: whether a refugee from Delphi, or somebody who's never touched Pascal before. You are working with an experimental version of the OS that will not be released until 2nd half 2023. That is not beginner refugee territory. So let's reboot the discussion. Is your quote above that 3.2.0 bootstrap works correct ? ---------------------------------------------------------------------- TRon · 2023-01-21 15:57 Quote from: marcov on January 21, 2023, 04:12:57 pmYou are working with an experimental version of the OS that will not be released until 2nd half 2023. That is not beginner refugee territory. A bit of a sidetrack (apologies) but I (for one) do not have a choice. There isn't a single (older) distribution that runs on this specific hardware unless I'm willing to custom compile the kernel (running a testing release is already new to me). Although I am able to understand the discussion wrt the correct starting compiler I do believe there are bigger fish to fry ? Am I correct when I state that the only variable in creating the compiler are the binutils (or am I missing something else there) ? (*) (*) which fwiw is version 2.40 ---------------------------------------------------------------------- marcov · 2023-01-21 16:06 Quote from: TRon on January 21, 2023, 04:57:27 pmQuote from: marcov on January 21, 2023, 04:12:57 pmYou are working with an experimental version of the OS that will not be released until 2nd half 2023. That is not beginner refugee territory. A bit of a sidetrack (apologies) but I (for one) do not have a choice. There isn't a single (older) distribution that runs on this specific hardware unless I'm willing to custom compile the kernel (running a testing release is already new to me). Although I am able to understand the discussion wrt the correct starting compiler I do believe there are bigger fish to fry ? Like? Which post summarizes your exact problem description when bootstrapping with 3.2.0 ? QuoteAm I correct when I state that the only variable in creating the compiler are the binutils (or am I missing something else there) ? (*) (*) which fwiw is version 2.40 Including possible modifications for the distribution (iow, is it vanilla 2.40?) I'm not Linux expert (anymore), but iirc there are also additional binaries like crti.o and crtn.o that come iirc with glibc- devel.   Easiest is to try compile something and use -s to view link.res and ppas.sh. Once for a binary that links  to libc, and once not. And of course the binary loader might also be different or have new requirements. (e.g. requiring some new section, a certain identifier etc) ---------------------------------------------------------------------- MarkMLl · 2023-01-21 21:47 Quote from: marcov on January 21, 2023, 05:06:03 pmLike? Which post summarizes your exact problem description when bootstrapping with 3.2.0 ? I'm stepping back from the forum for a while, I've had more than enough of this. PMs are set to send me an email alert. MarkMLl ---------------------------------------------------------------------- dbannon · 2023-01-21 22:53 Quote from: marcov on January 21, 2023, 04:12:57 pm You are working with an experimental version of the OS (Testing) that will not be released until 2nd half 2023. That is not beginner refugee territory. Thats possibly not quite accurate Marcov, many people use Testing, especially this late in its release cycle. Ubuntu and many other Linux Distribution are built as snapshots of Testing. I suspect you are thinking of 'unstable' or 'sid' - they sure are experimental. Testing has quite high standards and any package with problems in Testing is removed. Importantly, Testing, Bookworm at present, is what will be 'stable' before too long. If there is a problem there, we need to identify it and either work around it or report a bug. Once its released, it will be too late. Davo ---------------------------------------------------------------------- marcov · 2023-01-21 23:40 Quote from: dbannon on January 21, 2023, 11:53:06 pmThats possibly not quite accurate Marcov, many people use Testing, especially this late in its release cycle. Ubuntu and many other Linux Distribution are built as snapshots of Testing. I suspect you are thinking of 'unstable' or 'sid' - they sure are experimental. Testing has quite high standards and any package with problems in Testing is removed. Importantly, Testing, Bookworm at present, is what will be 'stable' before too long. If there is a problem there, we need to identify it and either work around it or report a bug. Once its released, it will be too late. In summary:   Mark has problems with building 3.2.2 with 3.0.4, a combination based on what seems to be allowed in the makefile. I say that is not an official route.  (though it is one that in general is quite commonly  doable, it was never guaranteed). See e.g. decade old buildfaq. In all cases: if you have problems building try the guaranteed working solution (full previous release install, and then bootstrap using the release source) TRon reports problems, but confirms 3.2.2 builds with 3.2.0, which is the supported way. I'm still waiting for his summary for what is the actual problem Sometimes it can help to pass -dFPC_USE_LIBC to temporarily generate a (g)libc using compiler binary using e.g. make cycle, and only then try to bootstrap with that glibc ppc386/x64 without -dFPC_USE_LIBC. As said before, running with -s and then manually run ppas.sh can sometimes be insightful too, and allow multiple link attempts with slightly different options (in case it has something to do with the -T stuff, which is something done for either 3.2.0 or 3.2.2). Speaking of which; TRon:  the linker (LD) also has some default linker scripts internally that might have changed. The -T change was something about that, with in the distance past the script on the commandline being a replacement, and later only an addition (or the other way around).  But it is more likely to appear with Lazarus binaries that use resources, as most of the script changes are related to that. ---------------------------------------------------------------------- TRon · 2023-01-22 06:26 Quote from: marcov on January 21, 2023, 05:06:03 pmLike? Which post summarizes your exact problem description when bootstrapping with 3.2.0 ? Sorry marcov. That was a remark from my hand that you obviously took into context of this thread. I meant on a more general note e.g.current bugs, new release etc. I do not have a problem bootstrapping with 3.2.0. I understand that it is not a concern of the team that older compilers won't build (however frustrating that might be for some). Thank you for your elaborated posts on my question regarding external factors that influences (or can influence) the build-process. I gladly take them into consideration in trying to figure out what goes wrong for the older builds. Whatever the culprit, it seems to have been addressed and/or fixed with 3.20 although I am aware it could be pure coincidence (which, if the case, is what concerns me more  ). @MarkMLI: Sorry to see that this discussion is upsetting you enough to turn away (if even for a while). That was not my intention when I bumped this thread. I just wanted to share my experience so that it won't come to a surprise (to others as well) in a coupe of months.  No problem if you do not (wish to) react (for the time being). ---------------------------------------------------------------------- dbannon · 2023-01-22 11:23 Quote from: TRon on January 22, 2023, 07:26:04 am Whatever the culprit, it seems to have been addressed and/or fixed with 3.20 although I am aware it could be pure coincidence (which, if the case, is what concerns me more  ). TRon, there are a lot of changes between compiler versions, otherwise there would not need to be new releases. So, rather than looking for a "culprit" you should be chalking up a win if you can do an unexpected build with a compiler earlier than the recommended one. But its a win by accident, not intentional, the devs don't try and support earlier compilers, if it happens, its a case of "gee, thats handy". Davo ---------------------------------------------------------------------- marcov · 2023-01-22 12:57 Quote from: TRon on January 22, 2023, 07:26:04 amQuote from: marcov on January 21, 2023, 05:06:03 pmLike? Which post summarizes your exact problem description when bootstrapping with 3.2.0 ? Sorry marcov. That was a remark from my hand that you obviously took into context of this thread. I meant on a more general note e.g.current bugs, new release etc. I do not have a problem bootstrapping with 3.2.0. Good. But then it is out of the hands of the FPC team nowadays. If the bootstrap stuff needs occasional maintenance to old branches that is done by them themselves. QuoteI understand that it is not a concern of the team that older compilers won't build (however frustrating that might be for some). The problem is that Linux binary standards are a (very slowly) moving target. An old source is however static, and there are complications like that source being tied to old tools (LD,AR,AS and make chiefly, but there are more detail dependencies).  Later versions reduce the dependency on AS/AR more and more. (using pascal startup code and an inernal assembler). The logical way would to periodically cross bootstrap from a binary stable target like Windows (*), but that is probably politically not doable on Debian.   If that is not possible, it would make sense to break the chain up and put them all in VMs of Debians of varying eras. That would decrease the maintenance for a new version at the expense of it remaining a mostly manual process. (*) Windows is also not 100% binary stable (e.g. Windows Vista breaking due to requiring manifests for e.g. "install" binaries, but it is miles better, and more importantly you don't have to redo it for each version every 3 years.   On Windows the binutils elimination is also quite complete (internal AS and LD and even an alternative to windres in the next major version) which further reduces complications. QuoteThank you for your elaborated posts on my question regarding external factors that influences (or can influence) the build-process. I gladly take them into consideration in trying to figure out what goes wrong for the older builds. Whatever the culprit, it seems to have been addressed and/or fixed with 3.20 although I am aware it could be pure coincidence (which, if the case, is what concerns me more  ). No problem. Note that the topic is not taboo and I will help where I can with questions, but to avoid contention be clear in your reasoning, and stay clear of the wordings that introduced the confusion with Mark  (using phrases as "should work", more or less demanding support for unsupported options, based what happened to work on old debians or allowed version in the Makefile). If you have n FPC versions that each ran on a couple debian versions from their time, you can imagine the version matrix.  And they all will have to made to run on a new version every 2-3 years. (see the VM remark above). If I were you I would find out how debian handles bootstrapping now. (if they bootstrapped once and now keep all versions generated with that as "blessed", or have a live setup they regularly use), and read the buildfaq (linked in the doc section of the freepascal site). It is an old and rambling document where I put a lot of what I found out about building  from source , cross or otherwise. ---------------------------------------------------------------------- dbannon · 2023-01-22 23:09 Quote from: marcov on January 22, 2023, 01:57:20 pmIf I were you I would find out how debian handles bootstrapping now. (if they bootstrapped once and now keep all versions generated with that as "blessed", or have a live setup they regularly use), and read the buildfaq (linked in the doc section of the freepascal site).... Debian, as a matter of policy, initially build on Sid, using Sid's current compiler. So, the latest FPC in Testing FPC.3.2.2-18, was initially built using FPC.3.2.2 (and presumably -17). The -17 and -18 refer to repackaging runs, can include application of custom patches. https://buildd.debian.org/status/fetch.php?pkg=fpc&arch=amd64&ver=3.2. 2%2Bdfsg-18&stamp=1673103546&raw=0 That rather surprises me because I though there was no guarantee that a FPC release can build itself ?  Not sure if that ever happens nor what Debian would then do ... Because Sid is a rolling release (using 'release' loosely) they would never be attempting to build with anything older than the immediate predecessor. Davo ---------------------------------------------------------------------- TRon · 2023-01-24 09:43 @marcov: Thank you very much again for such a extensive reply. That gave me exactly the input I required. Sorry to say/conclude that you probably could have have linked to this thread ergo I apologize for having wasted your time simply because I have been absent for a while (I did not notice that thread earlier nor the report in the bugtracker). There seem to be several issues, one mentioned as in the linked thread/tracker but second in that debian itself distributed a broken glibc version. Seems to have been fixed but I'd say there are still a few things off (see also my results). My bookworm system currently runs with GLIBC 2.36-8. Another issue seems to be related to (newly introduced ?) compressed sections. I did not fully understood the gist of it yet. I'll try to read into that later. As already mentioned/suggested in the aforementioned thread and repeated in your post it would currently be the best solution to do as advised and maintain several systems for backwards compatibility (for as long as required). I will do that for now (maintaining several different libc versions on a single system is a bit too much for me). Also thank you for the suggestion of having a look at your build-faq. I should be able to cite the contents of that FAQ from memory now, after having used it as a tome for all these years I'll have renewed look when some of that pesky dust settles down a bit. ---------------------------------------------------------------------- marcov · 2023-01-24 11:45 (the bootstrap compiler is a static binary, so shouldn't suffer from symbol versioning) ---------------------------------------------------------------------- TRon · 2023-01-24 12:26 @marcov: I agree that it should not matter, yet these errors persist. Since the builds seems to suggest to bail out on the linker i've tried using other binutil versions (2.30..2.39). None of them fixed the issues (it gets even worse but that is to be expected) But even the more strange: research seem to suggest I need even newer binutils (>2.40) to fix the issue (not a link present atm). I tried compiling FPC versions in backwards order (e.g. bootstrap newer than sources) but that only goes sofar (funny failures though)  Also there is the distinct mention of a missing section while linking, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023661 (bugreport mentions fixed for v2.36-5) At least I'm not the only one :-) ---------------------------------------------------------------------- TRon · 2023-01-24 15:09 Original issue:bootstrap=3.0.2 fpc=3.0.4 (default binutils 2.40) wrt msg2inc segmentation fault. Either stripped or not "file" tells it is a valid executable on both accounts. Invoking it (outside the build process) displays the segmentation fault. Code: [Select]make DEBUG=1 OPT="-O- -k--verbose=5" PP="${pp_bootstrap_compiler}" -- snip -- make -C utils cleanall make[6]: Entering directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler/utils' /usr/bin/rm -f fpc ppufiles ppudump ppumove mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmkarmins.a libimpmkx86ins.a /usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu /usr/bin/rm -rf units /usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh make[6]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler/utils' /usr/bin/rm -rf x86_64/units /usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl /usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcx64 x86_64/ppcppc x86_64/ppcsparc x86_64/ppcppc64 x86_64/ppcarm x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcjvm x86_64/ppc8086 x86_64/ppcx64 /usr/bin/rm -f ppcx64 /usr/bin/mkdir -p x86_64/units/x86_64-linux make ./msg2inc make[6]: Entering directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' /media/ramdisk-8gb/compilehostedfpc/bin/ppcx64-3.0.2 -gl -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/media/ramdisk- 8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dDEBUG -dRELEASE -O- -k-- verbose=5 -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp GNU ld (GNU Binutils for Debian) 2.40   Supported emulations:    elf_x86_64    elf32_x86_64    elf_i386    elf_iamcu    i386pep    i386pe using internal linker script: ================================================== /* Script for -z combreloc -z separate-code */ /* Copyright (C) 2014-2023 Free Software Foundation, Inc.    Copying and distribution of this script, with or without modification,    are permitted in any medium without royalty provided the copyright    notice and this notice are preserved.  */ OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",       "elf64-x86-64") OUTPUT_ARCH(i386:x86-64) ENTRY(_start) SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu64"); SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib"); SECTIONS {   PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;   .interp         : { *(.interp) }   .note.gnu.build-id  : { *(.note.gnu.build-id) }   .hash           : { *(.hash) }   .gnu.hash       : { *(.gnu.hash) }   .dynsym         : { *(.dynsym) }   .dynstr         : { *(.dynstr) }   .gnu.version    : { *(.gnu.version) }   .gnu.version_d  : { *(.gnu.version_d) }   .gnu.version_r  : { *(.gnu.version_r) }   .rela.dyn       :     {       *(.rela.init)       *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)       *(.rela.fini)       *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)       *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)       *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)       *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)       *(.rela.ctors)       *(.rela.dtors)       *(.rela.got)       *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)       *(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*)       *(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*)       *(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*)       *(.rela.ifunc)     }   .rela.plt       :     {       *(.rela.plt)       PROVIDE_HIDDEN (__rela_iplt_start = .);       *(.rela.iplt)       PROVIDE_HIDDEN (__rela_iplt_end = .);     }   .relr.dyn : { *(.relr.dyn) }   . = ALIGN(CONSTANT (MAXPAGESIZE));   .init           :   {     KEEP (*(SORT_NONE(.init)))   }   .plt            : { *(.plt) *(.iplt) } .plt.got        : { *(.plt.got) } .plt.sec        : { *(.plt.sec) }   .text           :   {     *(.text.unlikely .text.*_unlikely .text.unlikely.*)     *(.text.exit .text.exit.*)     *(.text.startup .text.startup.*)     *(.text.hot .text.hot.*)     *(SORT(.text.sorted.*))     *(.text .stub .text.* .gnu.linkonce.t.*)     /* .gnu.warning sections are handled specially by elf.em.  */     *(.gnu.warning)   }   .fini           :   {     KEEP (*(SORT_NONE(.fini)))   }   PROVIDE (__etext = .);   PROVIDE (_etext = .);   PROVIDE (etext = .);   . = ALIGN(CONSTANT (MAXPAGESIZE));   /* Adjust the address for the rodata segment.  We want to adjust up to      the same address within the page on the next page up.  */   . = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)));   .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }   .rodata1        : { *(.rodata1) }   .eh_frame_hdr   : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) }   .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) }   .sframe         : ONLY_IF_RO { *(.sframe) *(.sframe.*) }   .gcc_except_table   : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }   .gnu_extab   : ONLY_IF_RO { *(.gnu_extab*) }   /* These sections are generated by the Sun/Oracle C++ compiler.  */   .exception_ranges   : ONLY_IF_RO { *(.exception_ranges*) }   /* Adjust the address for the data segment.  We want to adjust up to      the same address within the page on the next page up.  */   . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));   /* Exception handling  */   .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) *(.eh_frame.*) }   .sframe         : ONLY_IF_RW { *(.sframe) *(.sframe.*) }   .gnu_extab      : ONLY_IF_RW { *(.gnu_extab) }   .gcc_except_table   : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }   .exception_ranges   : ONLY_IF_RW { *(.exception_ranges*) }   /* Thread Local Storage sections  */   .tdata   :    {      PROVIDE_HIDDEN (__tdata_start = .);      *(.tdata .tdata.* .gnu.linkonce.td.*)    }   .tbss   : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }   .preinit_array    :   {     PROVIDE_HIDDEN (__preinit_array_start = .);     KEEP (*(.preinit_array))     PROVIDE_HIDDEN (__preinit_array_end = .);   }   .init_array    :   {     PROVIDE_HIDDEN (__init_array_start = .);     KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))     KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))     PROVIDE_HIDDEN (__init_array_end = .);   }   .fini_array    :   {     PROVIDE_HIDDEN (__fini_array_start = .);     KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))     KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))     PROVIDE_HIDDEN (__fini_array_end = .);   }   .ctors          :   {     /* gcc uses crtbegin.o to find the start of        the constructors, so we make sure it is        first.  Because this is a wildcard, it        doesn't matter if the user does not        actually link against crtbegin.o; the        linker won't look for a file to match a        wildcard.  The wildcard also means that it        doesn't matter which directory crtbegin.o        is in.  */     KEEP (*crtbegin.o(.ctors))     KEEP (*crtbegin?.o(.ctors))     /* We don't want to include the .ctor section from        the crtend.o file until after the sorted ctors.        The .ctor section from the crtend file contains the        end of ctors marker and it must be last */     KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))     KEEP (*(SORT(.ctors.*)))     KEEP (*(.ctors))   }   .dtors          :   {     KEEP (*crtbegin.o(.dtors))     KEEP (*crtbegin?.o(.dtors))     KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))     KEEP (*(SORT(.dtors.*)))     KEEP (*(.dtors))   }   .jcr            : { KEEP (*(.jcr)) }   .data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }   .dynamic        : { *(.dynamic) }   .got            : { *(.got) *(.igot) }   . = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 24 ? 24 : 0, .);   .got.plt        : { *(.got.plt) *(.igot.plt) }   .data           :   {     *(.data .data.* .gnu.linkonce.d.*)     SORT(CONSTRUCTORS)   }   .data1          : { *(.data1) }   _edata = .; PROVIDE (edata = .);   . = .;   __bss_start = .;   .bss            :   {    *(.dynbss)    *(.bss .bss.* .gnu.linkonce.b.*)    *(COMMON)    /* Align here to ensure that the .bss section occupies space up to       _end.  Align after .bss to ensure correct alignment even if the       .bss section disappears because there are no input sections.       FIXME: Why do we need it? When there is no .bss section, we do not       pad the .data section.  */    . = ALIGN(. != 0 ? 64 / 8 : 1);   }   .lbss   :   {     *(.dynlbss)     *(.lbss .lbss.* .gnu.linkonce.lb.*)     *(LARGE_COMMON)   }   . = ALIGN(64 / 8);   . = SEGMENT_START("ldata-segment", .);   .lrodata   ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :   {     *(.lrodata .lrodata.* .gnu.linkonce.lr.*)   }   .ldata   ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :   {     *(.ldata .ldata.* .gnu.linkonce.l.*)     . = ALIGN(. != 0 ? 64 / 8 : 1);   }   . = ALIGN(64 / 8);   _end = .; PROVIDE (end = .);   . = DATA_SEGMENT_END (.);   /* Stabs debugging sections.  */   .stab          0 : { *(.stab) }   .stabstr       0 : { *(.stabstr) }   .stab.excl     0 : { *(.stab.excl) }   .stab.exclstr  0 : { *(.stab.exclstr) }   .stab.index    0 : { *(.stab.index) }   .stab.indexstr 0 : { *(.stab.indexstr) }   .comment       0 : { *(.comment) }   .gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }   /* DWARF debug sections.      Symbols in the DWARF debugging sections are relative to the beginning      of the section so we begin them at 0.  */   /* DWARF 1.  */   .debug          0 : { *(.debug) }   .line           0 : { *(.line) }   /* GNU DWARF 1 extensions.  */   .debug_srcinfo  0 : { *(.debug_srcinfo) }   .debug_sfnames  0 : { *(.debug_sfnames) }   /* DWARF 1.1 and DWARF 2.  */   .debug_aranges  0 : { *(.debug_aranges) }   .debug_pubnames 0 : { *(.debug_pubnames) }   /* DWARF 2.  */   .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }   .debug_abbrev   0 : { *(.debug_abbrev) }   .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end) }   .debug_frame    0 : { *(.debug_frame) }   .debug_str      0 : { *(.debug_str) }   .debug_loc      0 : { *(.debug_loc) }   .debug_macinfo  0 : { *(.debug_macinfo) }   /* SGI/MIPS DWARF 2 extensions.  */   .debug_weaknames 0 : { *(.debug_weaknames) }   .debug_funcnames 0 : { *(.debug_funcnames) }   .debug_typenames 0 : { *(.debug_typenames) }   .debug_varnames  0 : { *(.debug_varnames) }   /* DWARF 3.  */   .debug_pubtypes 0 : { *(.debug_pubtypes) }   .debug_ranges   0 : { *(.debug_ranges) }   /* DWARF 5.  */   .debug_addr     0 : { *(.debug_addr) }   .debug_line_str 0 : { *(.debug_line_str) }   .debug_loclists 0 : { *(.debug_loclists) }   .debug_macro    0 : { *(.debug_macro) }   .debug_names    0 : { *(.debug_names) }   .debug_rnglists 0 : { *(.debug_rnglists) }   .debug_str_offsets 0 : { *(.debug_str_offsets) }   .debug_sup      0 : { *(.debug_sup) }   .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }   /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } } ================================================== /usr/bin/ld: mode elf_x86_64 attempt to open ./link.res succeeded ./link.res opened script file ./link.res /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? attempt to open /media/ramdisk-8gb/compilehostedfpc/src/fpc- 3.0.4/rtl/units/x86_64-linux/prt0.o succeeded /media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64- linux/prt0.o attempt to open ./x86_64/units/x86_64-linux/msg2inc.o succeeded ./x86_64/units/x86_64-linux/msg2inc.o attempt to open /media/ramdisk-8gb/compilehostedfpc/src/fpc- 3.0.4/rtl/units/x86_64-linux/system.o succeeded /media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64- linux/system.o attempt to open /media/ramdisk-8gb/compilehostedfpc/src/fpc- 3.0.4/rtl/units/x86_64-linux/lnfodwrf.o succeeded /media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64- linux/lnfodwrf.o attempt to open /media/ramdisk-8gb/compilehostedfpc/src/fpc- 3.0.4/rtl/units/x86_64-linux/exeinfo.o succeeded /media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64- linux/exeinfo.o attempt to open /media/ramdisk-8gb/compilehostedfpc/src/fpc- 3.0.4/rtl/units/x86_64-linux/strings.o succeeded /media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/rtl/units/x86_64- linux/strings.o make[6]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' ./msg2inc msg/errore.msg msg msg make[5]: *** [Makefile:3858: msgtxt.inc] Segmentation fault make[5]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' make[4]: *** [Makefile:3971: next] Error 2 make[4]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' make[3]: *** [Makefile:3975: ppc1] Error 2 make[3]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' make[2]: *** [Makefile:3987: cycle] Error 2 make[2]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4/compiler' make[1]: *** [Makefile:2780: compiler_cycle] Error 2 make[1]: Leaving directory '/media/ramdisk-8gb/compilehostedfpc/src/fpc-3.0.4' make: *** [Makefile:2812: build-stamp.x86_64-linux] Error 2 A 193mb log from LD_DEBUG=ALL is such overwhelming that I am unable to see a tree in the forest  Next step is to check what building 3.2.2 shows us. edit: it seems that msg2inc will not run without elevated rights (i am the owner, group owner and the executable has all required read/write rights). I have never seen that before and the source of msg2inc does not seem to justify that requirement (unless I missed something) . Anybody out there that is able to shed a light on how to further debug (gdb does not have a backtrace) ? Or is it simply the 'first call' to getrlimit that is failing when called without elevated rights ? ---------------------------------------------------------------------- MarkMLl · 2024-10-05 07:27 Quote from: TRon on January 24, 2023, 04:09:59 pmOriginal issue:bootstrap=3.0.2 fpc=3.0.4 (default binutils 2.40) wrt msg2inc segmentation fault. Either stripped or not "file" tells it is a valid executable on both accounts. Invoking it (outside the build process) displays the segmentation fault. ... edit: it seems that msg2inc will not run without elevated rights (i am the owner, group owner and the executable has all required read/write rights). I have never seen that before and the source of msg2inc does not seem to justify that requirement (unless I missed something) . Anybody out there that is able to shed a light on how to further debug (gdb does not have a backtrace) ? Or is it simply the 'first call' to getrlimit that is failing when called without elevated rights ? Basically, the "won't run without elevated rights" issue appears to apply to all versions of FPC older than 3.2 when running on Debian 12, and it also applies to any program built on Debian 12: not just intermediates when building the compiler. The reason the compilers themselves in the examples below work is that they were built on Debian 11, hence this might- or might not- be related to the Symbol Versioning issues discussed in the long thread at https://forum.lazarus.freepascal.org/index.php/topic,64731.0.html Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program test; beginend.  Obviously if that runs it won't generate any output, but neither should it crash. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ~$ fpc -V3.2.2 test.pas && ./testFree Pascal Compiler version 3.2.2 [2022/10/24] for x86_64Copyright (c) 1993-2021 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling test.pasLinking test5 lines compiled, 0.1 sec ~$ fpc -V3.2.0 test.pas && ./testFree Pascal Compiler version 3.2.0 [2022/10/24] for x86_64Copyright (c) 1993-2020 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling test.pasLinking test5 lines compiled, 0.2 sec ~$ fpc -V3.0.4 test.pas && ./testFree Pascal Compiler version 3.0.4 [2022/10/24] for x86_64Copyright (c) 1993-2017 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling test.pasLinking test/usr/bin/ld: warning: link.res contains output sections; did you forget -T?5 lines compiled, 0.1 secSegmentation fault ~$ sudo ./test[sudo] password for markMLl: This is obviously something which will not be fixed, but it would still be nice to work out what's going on since some older versions of FPC are worth having for testing purposes. Is this behaviour documented anywhere? MarkMLl ---------------------------------------------------------------------- MarkMLl · 2024-10-06 07:49 Probably my last word on this unless anybody has any suggestions: it's "way above my pay grade". Code: [Select]Segmentation fault Basically, this appears to be a completely different problem from the "symbol versioning" one, and is caused by the fact that the linker command has been reworked to- and I know there's much more to it than this- address the issue Code: [Select]/usr/bin/ld: warning: link.res contains output sections; did you forget -T? This happened between FPC 3.0 and 3.2 as can be seen if one uses the -sh option to generate ppas.sh and link.res files. The later versions add the -T option (I think Jonas explained the reason it had been omitted to me at one point), and the result is a substantial change in output structure even though the linker version is the same. If one wants a version of FPC for x86_64 in the range 2.6.4 through 3.0.4 to run on Debian 12, one has to build it on Debian 11. But even if it will run on Debian 12, the binaries it builds probably won't. The error message might not even be the result of code generated by the compiler, which is why gdb can't get a grip on it. The structure of the executable binary is different between 3.0 and 3.2, and that might simply be the kernel's way of announcing that it's rejecting it for security reasons: which is why it will run if invoked using sudo etc. MarkMLl