[SOLVED] FreeBSD 12.0 - FPC 3.3.1 build failure lazarus / 66-Unix ---------------------------------------------------------------------- trev · 2019-07-13 07:47 Building 3.3.1 on FreeBSD 12.0 (using ld soft-linked to ld.bfd) and: Code: [Select]gmake[5]: Leaving directory '/usr/local/share/fpc-3.3.1/compiler' gmake rtl gmake[5]: Entering directory '/usr/local/share/fpc-3.3.1/compiler' gmake -C /usr/local/share/fpc-3.3.1/rtl 'OPT=   ' all gmake[6]: Entering directory '/usr/local/share/fpc-3.3.1/rtl' gmake -C freebsd all gmake[7]: Entering directory '/usr/local/share/fpc-3.3.1/rtl/freebsd' as --64 -o /usr/local/share/fpc-3.3.1/rtl/units/x86_64-freebsd/prt0.o x86_64/prt0.as as --64 -o /usr/local/share/fpc-3.3.1/rtl/units/x86_64-freebsd/cprt0.o x86_64/cprt0.as as --64 -o /usr/local/share/fpc-3.3.1/rtl/units/x86_64-freebsd/gprt0.o x86_64/gprt0.as as --64 -o /usr/local/share/fpc-3.3.1/rtl/units/x86_64-freebsd/dllprt0.o x86_64/dllprt0.as /usr/local/share/fpc-3.3.1/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fi../bsd -Fi../bsd/x86_64 -Fi../freebsd/x86_64 -FE. -FU/usr/local/share/fpc-3.3.1/rtl/units/x86_64-freebsd -Cg -dx86_64 -dRELEASE  -Us -Sg ../bsd/system.pp Error: Path "./" does not exist It looks like the FPC compiler does not understand the . (dot) directory -- but it does! Typing gmake in the rtl subdirectory: Code: [Select]/usr/local/bin/ppcx64 -Fi../inc -Fi../x86_64 -Fi../unix -Fi../bsd -Fi../bsd/x86_64 -Fi../freebsd/x86_64 -FE. -FU../../rtl/units/x86_64-freebsd -Cg -dx86_64 ../objpas/fpwidestring.pp Free Pascal Compiler version 3.0.4 [2019/07/13] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: FreeBSD for x86-64 Compiling ../objpas/fpwidestring.pp 903 lines compiled, 0.1 sec gmake[1]: Leaving directory '/usr/local/share/fpc-3.3.1/rtl/freebsd' First line, "-FE." and no complaints, everything is compiled. So near and yet so far... (FPC 3.0.4 builds without issues) [Later: Ahh, I see the first compiler is a freshly compiled ppc1 whereas the second gmake is calling the installed (3.0.4) ppcx64. But why does ppc1 not understand dot directories?] ---------------------------------------------------------------------- marcov · 2019-07-13 10:51 Afaik this is because the llvm toolchain linker just drops what it doesn't know, and the resulting binaries are silently corrupted. In this case the corruption probably hits something related to directory searching (or fpaccess, which is used for fileexists iirc). There primitives are used for expandfilename and friends, which is what yields the error you get. ---------------------------------------------------------------------- trev · 2019-07-13 14:11 I thought not using lld as the linker but using ld.bfd avoided the llvm linker issues? ---------------------------------------------------------------------- marcov · 2019-07-13 14:52 Quote from: trev on July 13, 2019, 04:11:06 pmI thought not using lld as the linker but using ld.bfd avoided the llvm linker issues? Then I don't know. I built trunk on freebsd12 x86_64 in march and that went fine. The only thing I can imagine is that I maybe  used brandelf to make the 3.0.4 compiler "native" though. ---------------------------------------------------------------------- trev · 2019-07-13 22:50 Code: [Select]trev@fbsd [/home/trev] $ file `which fpc` /usr/local/bin/fpc: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, stripped trev@fbsd [/home/trev] $ brandelf `which fpc` File '/usr/local/bin/fpc' is of brand 'FreeBSD' (9). trev@fbsd [/home/trev] $ file `which ppcx64` /usr/local/bin/ppcx64: symbolic link to ../lib/fpc/3.0.4/ppcx64 trev@fbsd [/home/trev] $ file /usr/local/lib/fpc/3.0.4/ppcx64 /usr/local/lib/fpc/3.0.4/ppcx64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, stripped trev@fbsd [/home/trev] $ brandelf /usr/local/lib/fpc/3.0.4/ppcx64 File '/usr/local/lib/fpc/3.0.4/ppcx64' is of brand 'FreeBSD' (9). No need for brandelf, 3.0.4 was a locally compiled fpc from the FreeBSD ports collection which came with this bootstrap compiler binary: -rwxr-xr-x  1 1106  493     3.2M 28 Nov  2017 ppcx64-3.0.4-freebsd Hmmm. ---------------------------------------------------------------------- trev · 2019-07-18 02:00 The build failure was not resolved, but julkas was kind enough to share his solution for getting FPC 3.3.1 running on FreeBSD 12 with me. The solution: download the current FreeBSD FPC 3.3.1 snapshot and install it over the existing FPC 3.0.4 (sort of - I kept the sources and lib directory separate, but mostly overwrote the /usr/local/bin files only saving a few by soft linking eg, ln -s /usr/local/lib/fpc/3.3.1/ppcx64 /usr/local/bin/ppcx64). ---------------------------------------------------------------------- marcov · 2019-07-18 08:23 Quote from: trev on July 14, 2019, 12:50:08 amNo need for brandelf, 3.0.4 was a locally compiled fpc from the FreeBSD ports collection which came with this bootstrap compiler binary: -rwxr-xr-x  1 1106  493     3.2M 28 Nov  2017 ppcx64-3.0.4-freebsd Hmmm. I was referring to the ELF id tag with the ABI version in it. Which is what brandelf changes. ---------------------------------------------------------------------- trev · 2019-07-21 09:16 I think I've found the problem. I compiled an application on FreeBSD 12.0-RELEASE but it core dumped when moved to FreeBSD 12.0-STABLE. My STABLE system has a custom kernel, whereas the RELEASE system has a GENERIC kernel which includes the kitchen sink (ie almost every device driver and option). Eureka moment. The solution to the application core dumping was to rebuild the kernel with the following options uncommented: options         COMPAT_FREEBSD32        # Compatible with i386 binaries options         COMPAT_FREEBSD4         # Compatible with FreeBSD4 options         COMPAT_FREEBSD5         # Compatible with FreeBSD5 options         COMPAT_FREEBSD6         # Compatible with FreeBSD6 options         COMPAT_FREEBSD7         # Compatible with FreeBSD7 options         COMPAT_FREEBSD9         # Compatible with FreeBSD9 options         COMPAT_FREEBSD10        # Compatible with FreeBSD10 options         COMPAT_FREEBSD11        # Compatible with FreeBSD11 The particular system call that was causing the application to core dump (mmap) dates back to FreeBSD 6 in 2008: Code: [Select]compat6.mmap()                           ERR#78 'Function not implemented' SIGNAL 12 (SIGSYS) code=SI_KERNEL process killed, signal = 12 (core dumped) I'll now try building trunk with the reconfigured kernel. ---------------------------------------------------------------------- Xor-el · 2019-07-21 09:34 Quote from: trev on July 21, 2019, 11:16:17 amI think I've found the problem. I compiled an application on FreeBSD 12.0-RELEASE but it core dumped when moved to FreeBSD 12.0-STABLE. My STABLE system has a custom kernel, whereas the RELEASE system has a GENERIC kernel which includes the kitchen sink (ie almost every device driver and option). Eureka moment. The solution to the application core dumping was to rebuild the kernel with the following options uncommented: options         COMPAT_FREEBSD32        # Compatible with i386 binaries options         COMPAT_FREEBSD4         # Compatible with FreeBSD4 options         COMPAT_FREEBSD5         # Compatible with FreeBSD5 options         COMPAT_FREEBSD6         # Compatible with FreeBSD6 options         COMPAT_FREEBSD7         # Compatible with FreeBSD7 options         COMPAT_FREEBSD9         # Compatible with FreeBSD9 options         COMPAT_FREEBSD10        # Compatible with FreeBSD10 options         COMPAT_FREEBSD11        # Compatible with FreeBSD11 The particular system call that was causing the application to core dump (mmap) dates back to FreeBSD 6 in 2008: Code: [Select]compat6.mmap()                           ERR#78 'Function not implemented' SIGNAL 12 (SIGSYS) code=SI_KERNEL process killed, signal = 12 (core dumped) I'll now try building trunk with the reconfigured kernel. Interesting find. Please keep us updated. ---------------------------------------------------------------------- trev · 2019-07-21 12:56 Alas, it still fails to build because the created bootstrap compiler still cannot find dot paths At least my application now runs without crashing