Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5

[TCH]

I don't see a Linux to OpenBSD crosscompiler here either. This one is a native one (file fpcupdeluxe-x86_64-openbsd):

Code: [Select]

fpcupdeluxe-x86_64-openbsd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.so, for OpenBSD, strippedI'd do the symlinking, but /usr/lib/libpthread.so.26.1 already exists. What should i do with it? Back it up and do the symlinking, or use it as it is?

[Fred vS]

I used the application /fpcupdeluxe/fpcupdeluxe-x86_64-linux and added the cross compiler.
https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/

And then to cross compile to OpenBSD:

Code: Pascal  [Select][+][-]

1. /home/fred/fpcupdeluxe/fpc/bin/x86_64-linux/ppcrossx64 -Topenbsd myapp.pas

[TCH]

Thank you. I've found it, installed it and added the OpenBSD AMD64 crosscompiler. However, when i try to run fpcupdeluxe/fpc/bin/x86_64-linux/ppcrossx64 -Topenbsd hello.pas:

Code: [Select]

Free Pascal Compiler version 3.2.2-r0d122c49 [2024/06/14] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: OpenBSD for x86-64
Compiling hello.pas
Fatal: Can't find unit system used by hello
Fatal: Compilation aborted

[Fred vS]

Thank you. I've found it, installed it and added the OpenBSD AMD64 crosscompiler. However, when i try to run fpcupdeluxe/fpc/bin/x86_64-linux/ppcrossx64 -Topenbsd hello.pas:

Code: [Select]

Free Pascal Compiler version 3.2.2-r0d122c49 [2024/06/14] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: OpenBSD for x86-64
Compiling hello.pas
Fatal: Can't find unit system used by hello
Fatal: Compilation aborted

Not sure it is the same problem than your but after adding new cross compiler, I had to replace the /etc/fpc.cfg with the one from fpcupdeluxe.

Code: Pascal  [Select][+][-]

1. > sudo cp -f /home/fred/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.cfg /etc/fpc.cfg

[TRon]

However, when i try to run fpcupdeluxe/fpc/bin/x86_64-linux/ppcrossx64 -Topenbsd hello.pas:

Code: [Select]

Free Pascal Compiler version 3.2.2-r0d122c49 [2024/06/14] for x86_64

FPCUpDeluxe generates a fpc.sh shell script for a reason -> you just found it 

[TCH]

Not sure it is the same problem than your but after adding new cross compiler, I had to replace the /etc/fpc.cfg with the one from fpcupdeluxe.

Code: Pascal  [Select][+][-]

1. > sudo cp -f /home/fred/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.cfg /etc/fpc.cfg

It worked, thank you. The binary i got runs on OpenBSD 7.5.

FPCUpDeluxe generates a fpc.sh shell script for a reason -> you just found it 

Yep, now that you say, i found it, thanks.

Maybe i can cross-compile Lazarus like this.

[TCH]

Yes, i could compile it. I needed to do the very same tweaks as before (copying the cnetdb.pas to the units dir, making a fake revision.inc and passing USESVN2REVISIONINC=0 to gmake) and more (also passing PP=/root/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh to gmake and adding -Topenbsd to /root/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh (it did not worked if i added the flag to the config)), but it worked.

Unfortunately, when i try to run the result on OpenBSD, the results are almost the same.

startlazarus:

Code: [Select]

[?1034hGNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd7.5"...
(gdb) run
Starting program: /tmp/lazarus/startlazarus
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Program received signal SIGFPE, Arithmetic exception.
0x000000024c3f939b in hb_font_t::mults_changed ()
   from /usr/local/lib/libharfbuzz.so.18.7
(gdb) step
Single stepping until exit from function _ZN9hb_font_t13mults_changedEv,
which has no line number information.

(startlazarus:95638): GLib-GObject-CRITICAL **: 23:56:40.647: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Program received signal SIGSEGV, Segmentation fault.
0x000000027580c768 in signal_emit_unlocked_R.123 ()
   from /usr/local/lib/libgobject-2.0.so.4200.18
(gdb) step
Single stepping until exit from function signal_emit_unlocked_R.123,
which has no line number information.

Program received signal SIGFPE, Arithmetic exception.
[Switching to thread 126049]
FcCharSetFindLeafCreate (fcs=0x2e95f49c0, ucs4=119808)
    at /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fccharset.c:110
110 /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fccharset.c: No such file or directory.
in /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fccharset.c
Current language:  auto; currently minimal
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x0000000238e79000 in ?? ()
(gdb) step
Cannot find bounds of current function
(gdb) quit
The program is running.  Exit anyway? (y or n) lazarus:

Code: [Select]

[?1034hGNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd7.5"...
(gdb) run
Starting program: /tmp/lazarus/lazarus
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Program received signal SIGFPE, Arithmetic exception.
0x000000022249339b in hb_font_t::mults_changed ()
   from /usr/local/lib/libharfbuzz.so.18.7
(gdb) step
Single stepping until exit from function _ZN9hb_font_t13mults_changedEv,
which has no line number information.

(lazarus:66912): GLib-GObject-CRITICAL **: 23:58:23.474: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Program received signal SIGSEGV, Segmentation fault.
0x0000000230e76768 in signal_emit_unlocked_R.123 ()
   from /usr/local/lib/libgobject-2.0.so.4200.18
(gdb) step
Single stepping until exit from function signal_emit_unlocked_R.123,
which has no line number information.
Die: DW_TAG_set_type (abbrev = 36, offset = 4539496)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_string) string: "TCOMPONENTSTATE"
DW_AT_byte_size (DW_FORM_data2) constant: 4
DW_AT_type (DW_FORM_ref4) constant ref: 4539519 (adjusted)
Dwarf Error: Cannot find type of die [in module /tmp/lazarus/lazarus]
(gdb) step
Die: DW_TAG_set_type (abbrev = 36, offset = 4539496)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_string) string: "TCOMPONENTSTATE"
DW_AT_byte_size (DW_FORM_data2) constant: 4
DW_AT_type (DW_FORM_ref4) constant ref: 4539519 (adjusted)
Dwarf Error: Cannot find type of die [in module /tmp/lazarus/lazarus]
(gdb) quit
The program is running.  Exit anyway? (y or n)

[Fred vS]

Hello.

Did you do?:

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

1. > objdump -x lazarus | grep ' NEEDED '

Check the libraries needed then with:

Code: Pascal  [Select][+][-]

1. > find /usr/ -name theneededlib.so*

If not found, create a symlink like explained in previous post.

[TCH]

Yes i did. I did not checked all the dependencies, just libc, libpthread and libX11, but they were OK. But the error message is also the same as before: floating point exception in the harfbuzz library; it did not reported a missing library.

[Fred vS]

Yes i did. I did not checked all the dependencies, just libc, libpthread and libX11, but they were OK. But the error message is also the same as before: floating point exception in the harfbuzz library; it did not reported a missing library.

Did you try to cross-compile a simple Lazarus app (not all the Lazarus project)?

[TCH]

I did not try to crosscompile it, because i have no idea how could i do it. I'd need a cross-Lazarus for that.

But you gave me an idea. startlazarus and lazarus may crash because something in their GUI handling is not working well with the new harfbuzz library, but lazbuild is a CLI program, so i can try to build a Lazarus app with it, natively. So, i did a gmake install and then tried to build my app. It did not worked, because apparently, the install process did not copy the needed Lazarus sources from it's tree, to it's units dir. With trial and error, i copied all of them and then lazbuild worked and my app has succesfully been built.

But my app also crashed with the same error: SIGFPE in harfbuzz's mults_changed() function.

Whatever is the problem, it does not matter if one build the app natively, or via cross-compiling. Something changed in OpenBSD's harfbuzz library between 8.2.1 and 8.3.0 and Lazarus cannot handle that.

I guess, the next step would be to build harfbuzz 8.3.0 with debug symbols and try to find what happens. (My bet is a division by zero in that function, but the caller is unknown, both in harfbuzz and Lazarus.)

[TRon]

I did not try to crosscompile it, because i have no idea how could i do it. I'd need a cross-Lazarus for that.

Provided that you have setup FPC compiler (and cross-compiler) correctly (that includes dependencies of/for the target) and that Lazarus supports the target you do not require a 'cross-lazarus' (whatever that means in your terminology).

Just start Lazarus on whatever host, develop your application and then set the project options to compile for a specific target (openbsd in your case, and a specific widgetset) and Lazarus will automatically build the application for you for the chosen target. Ofc the resulted binary will not run on your host unless the host is the same as your configured target.

see also wiki.

[TRon]

Whatever is the problem, it does not matter if one build the app natively, or via cross-compiling.

Indeed that does not matter.

Something changed in OpenBSD's harfbuzz library between 8.2.1 and 8.3.0 and Lazarus cannot handle that.

just fwiw it is not Lazarus at fault here. You would be better spend your energy in figuring out what changed in/with openbsd. As already suggested by Marcov there is a simple workaround but that is all it is.

When your OS entwine itself with c then c-rules apply, hence my suggestion to try and figure out what changed in/for OpenBSD. Perhaps it is possible to address the change in FPC the same way it was done in/for c.

I guess, the next step would be to build harfbuzz 8.3.0 with debug symbols and try to find what happens. (My bet is a division by zero in that function, but the caller is unknown, both in harfbuzz and Lazarus.)

Know that c allows for certain exceptions to be ignored. and again as suggested by marcov you can change that behaviour in/for FPC as well.

[Fred vS]

I did not try to crosscompile it, because i have no idea how could i do it. I'd need a cross-Lazarus for that.

First install Lazarus from fpcupdeluxe.

Load that version and for your project options select the target os (see picture).
Compile it (but dont run it, test it on your OpenBSD system).

Yes, i could compile it. I needed to do the very same tweaks as before (copying the cnetdb.pas to the units dir, making a fake revision.inc and passing USESVN2REVISIONINC=0 to gmake) and more (also passing PP=/root/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh to gmake and adding -Topenbsd to /root/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh (it did not worked if i added the flag to the config)), but it worked.

Unfortunately, when i try to run the result on OpenBSD, the results are almost the same.

Wow, already a big step forward if you are able to cross compile Lazarus.
Do you think you might be able to compile fpc itself?
Use fpc from fpcupdeluxe compiled with fpc_3.2_fixes and update all libraries in fpcupdeluxe/cross/lib/x86_64-openbsd/ with OpenBSD 7.5 libraries.
Indeed, big job if these libraries have to be found + added one by one.

Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

This is a error from the debugger, it seems that it does not like some optimization:
https://stackoverflow.com/questions/11671009/dwarf-error-wrong-version-in-compilation-unit-header-is-4-should-be-2

Did you try to run without debugger and compiled without optimization?

[TCH]

Provided that you have setup FPC compiler (and cross-compiler) correctly (that includes dependencies of/for the target) and that Lazarus supports the target you do not require a 'cross-lazarus' (whatever that means in your terminology).

Just start Lazarus on whatever host, develop your application and then set the project options to compile for a specific target (openbsd in your case, and a specific widgetset) and Lazarus will automatically build the application for you for the chosen target. Ofc the resulted binary will not run on your host unless the host is the same as your configured target.

see also wiki.

First install Lazarus from fpcupdeluxe.

Load that version and for your project options select the target os (see picture).
Compile it (but dont run it, test it on your OpenBSD system).

Thanks guys. Although now it does not really matter anymore.

just fwiw it is not Lazarus at fault here. You would be better spend your energy in figuring out what changed in/with openbsd. As already suggested by Marcov there is a simple workaround but that is all it is.

When your OS entwine itself with c then c-rules apply, hence my suggestion to try and figure out what changed in/for OpenBSD. Perhaps it is possible to address the change in FPC the same way it was done in/for c.

Know that c allows for certain exceptions to be ignored. and again as suggested by marcov you can change that behaviour in/for FPC as well.

To defer linking and link by hand? Since the problem is most likely in the OS and not in the FreePascal/Lazarus ecosystem, what difference that will make? Or to try with simple programs first? The problem only appears with Lazarus apps (but even in the simples ones (empty form only)), so i cannot do that.

Wow, already a big step forward if you are able to cross compile Lazarus.
Do you think you might be able to compile fpc itself?
Use fpc from fpcupdeluxe compiled with fpc_3.2_fixes and update all libraries in fpcupdeluxe/cross/lib/x86_64-openbsd/ with OpenBSD 7.5 libraries.
Indeed, big job if these libraries have to be found + added one by one.

I might would be able to compile the fixed FPC too, but to what point now? The problem is not in the FreePascal/Lazarus ecosystem, but in the OS.

Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

This is a error from the debugger, it seems that it does not like some optimization:
https://stackoverflow.com/questions/11671009/dwarf-error-wrong-version-in-compilation-unit-header-is-4-should-be-2

Did you try to run without debugger and compiled without optimization?

I tried without debug (did not touch optimization), but crashed anyway.

Other infos: i tried to run that plain form app, compiled on OpenBSD 7.4 with Lazarus 2.2.6. GTK2 version reported this:

Code: [Select]

(project1:55473): GLib-GObject-CRITICAL **: 21:54:24.528: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00000308E9F89768
  $00000308E9F8780E
  $00000308E9F8802F
  $00000309445D2DCE
  $00000308E9F7344D
  $00000309445D1226
  $00000306579B9BD2  FREESTYLEOBJECT,  line 7715 of gtk2proc.inc
  $00000306579B9CF7  RELEASEALLSTYLES,  line 7742 of gtk2proc.inc
  $000003065781A5F1  FREEALLSTYLES,  line 1650 of gtk2widgetset.inc
  $000003065781A6FF  GTK2DESTROY,  line 1712 of gtk2widgetset.inc
  $00000306578190AF  DESTROY,  line 1103 of gtk2widgetset.inc
  $0000030657818F40  CREATE,  line 1095 of gtk2widgetset.inc
  $00000306577F401A  CREATEWIDGETSET,  line 2243 of forms.pp
  $00000306577F2E83  INTERFACES_$$_init$,  line 35 of interfaces.pas
[FORMS.PP] ExceptionOccurred I tried to trace it back, but no luck: in gtk2widgetset.inc at line 1095, there is an end of the function called from one level above (CreateWidgetset(TGtk2WidgetSet); -> WidgetSet := AWidgetsetClass.Create;). I also recompiled harfbuzz 8.3.0 with debug infos and tried to step the app to see where it died. No luck, refused to go, by "unknown mode of die" or something.

However. I built that plain form app with GTK3 instead of GTK2 on OpenBSD 7.4 with Lazarus 2.2.6 and then tried that executable on the updated OpenBSD 7.5. And it worked.

I think this proves it: the problem is inside the OS, not FreePascal or Lazarus. (I mean the harfbuzz crash, the problem causing the segfaults still can be on either side.)

So, the solution now will be a GTK3 version for OpenBSD 7.5. Better than nothing.

Thank everyone in the topic for your help, i really appreciate it.