Forum > Other
Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
TRon:
--- Quote from: TCH on June 09, 2024, 11:35:14 pm ---http://downloads.freepascal.org/fpc/snapshot/fixes/source/fpc.zip or http://downloads.freepascal.org/fpc/snapshot/fixes/source/fpcbuild.zip?
--- End quote ---
You can however I personally prefer this as it is directly from the horses mouth. Other archive formats can be downloaded from here (press the code link).
Alternatively use git (the recommended way of doing things)
TCH:
Okay, thanks guys. In the following days, i'll try to make some time to build the compiler and then try to compile Lazarus with that.
marcov:
--- Quote from: TCH on June 09, 2024, 11:35:14 pm ---http://downloads.freepascal.org/fpc/snapshot/fixes/source/fpc.zip or http://downloads.freepascal.org/fpc/snapshot/fixes/source/fpcbuild.zip?
--- End quote ---
I don't know if those are up to date. Very low usage, so a hanging job isn't always detected. Better use git.
--- Quote from: TCH on June 09, 2024, 11:35:14 pm ---
I think those error messages are caused by some kind of ABI-breakage. I've already ran into a similar case when i upgraded OpenBSD 7.2 to 7.3. Lazarus 2.2.6 currently works on OpenBSD 7.4 and i can even upgrade to 7.5, it will work then too. It only dies, when i upgrade the harfbuzz package after the system upgrade. (.libs1-harfbuzz-2.9.1+.libs1-harfbuzz-5.2.0+harfbuzz-8.2.1 updated to harfbuzz-8.3.0, i've reported the issue to ibara.)
--- End quote ---
Is openbsd currently a libc port (like Darwin) or a syscall port like Linux/FreeBSD ? if it is a libc port, it shouldn't do syscalls, so the abi breakage should be wrapped.
If you have a working target system, can you run an older compiler on there ? (e.g. a linux one in some linuxator or an older OpenBSD version that selects older binaries based on ELF ident selector like on FreeBSD
Then you can try to build the compiler manually (first RTL, then make all in compiler/) and pass -S to defer linking.
Then run the link step manually (now started as a native program, as it is not executed by a compatibility/linux program)
Similarly, you can try to do this on an older system, and then transfer .o and ppas.sh and execute the link.
Linking natively uses some startup .o files that come with the system.
If this all fails, it is a bit more involved, and really finding out what is going on is needed, followed by (probably) startup code changes.
If the compiler seems to work, but can't find files, probably some stat or statfs struct changed. Print size of *nix related records in FPC on your old openbsd, and in a C program in new openbsd, and compare.
TCH:
--- Quote from: marcov on June 10, 2024, 03:03:32 pm ---Is openbsd currently a libc port (like Darwin) or a syscall port like Linux/FreeBSD ? if it is a libc port, it shouldn't do syscalls, so the abi breakage should be wrapped.
--- End quote ---
I have no idea. But speaking of syscalls, OpenBSD 7.5 removed support for syscall() and replaced it with pinsyscalls(). This might be the problem, although if it is, then i don't get it, why the existing Lazarus die only after harfbuzz has been upgraded...
--- Quote from: marcov on June 10, 2024, 03:03:32 pm ---If you have a working target system, can you run an older compiler on there ? (e.g. a linux one in some linuxator or an older OpenBSD version that selects older binaries based on ELF ident selector like on FreeBSD
Then you can try to build the compiler manually (first RTL, then make all in compiler/) and pass -S to defer linking.
Then run the link step manually (now started as a native program, as it is not executed by a compatibility/linux program)
Similarly, you can try to do this on an older system, and then transfer .o and ppas.sh and execute the link.
Linking natively uses some startup .o files that come with the system.
--- End quote ---
I can install any older FPC, but should not the sources be built with the latest stable one? Anyway, i tried to build the compiler sources got from the link TRon gave with the existing 3.2.2. It did not go well, the Makefile is erroneous, or i don't know. http://oscomp.hu/depot/make_all.log
Should i try to build it with an older compiler?
--- Quote from: marcov on June 10, 2024, 03:03:32 pm ---If this all fails, it is a bit more involved, and really finding out what is going on is needed, followed by (probably) startup code changes.
If the compiler seems to work, but can't find files, probably some stat or statfs struct changed. Print size of *nix related records in FPC on your old openbsd, and in a C program in new openbsd, and compare.
--- End quote ---
I've printed the sizes of struct stat and struct statfs on both 7.4 and 7.5: it is 128 and 568 on both, no changes have occurred.
duralast:
--- Quote ---Security improvements:
Introduce pinsyscalls(2): The kernel and ld.so(1) register the precise entry location of every system call used by a program, as described in the new ELF section .openbsd.syscalls inside ld.so and libc.so. ld.so uses the new syscall pinsyscalls(2) to tell the kernel the precise entry location of system calls in libc.so.
Attempting to use a different system call entry instruction to perform a non-corresponding system call operation will fail and the process will be terminated with signal SIGABRT.
Removed support for syscall(2), the "indirection system call," a dangerous alternative entry point for all system calls.
Together with pinsyscalls(2) this change makes it impossible to perform system call through any other way than the libc system call wrapper functions.
Users of syscall(2), such as Perl and the Go programming language were converted to use the libc functions.
--- End quote ---
As you noted, pinsyscalls(2) is your problem.
Theo even noted in an email on 27 Oct 2023, "There's going to be some fallout which takes time to fix, especially in the "go" ecosystem."
Obviously, it is more than just Perl and Go.
Navigation
[0] Message Index
[#] Next page
[*] Previous page