Recent

Author Topic: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5  (Read 18300 times)

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #30 on: June 11, 2024, 01:12:16 pm »
Can you try a rebuild with additional argument OPT="-O-" and see if that helps ?
Nope. gmake all OPT="-O-" only produced much more error messages: http://oscomp.hu/depot/gmake_all2.log
Maybe it is better to start the generated compiler (  compiler/ppc1) in gdb, and then get the traceback where it sigsegvs.

But there is a chance that this happens in startup code etc, if they messed with libc going from version to version.
I'd like to try skipping svn2revision before. So, you say, all i have to do is put revision.inc to the place where it looks for it and put the missing constants and functions into it? And then gmake bigide USESVN2REVISIONINC=0?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #31 on: June 11, 2024, 01:47:50 pm »
That's what I woudl try, yes. Careful, make clean might kill the file, so keep a copy somewhere

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #32 on: June 11, 2024, 05:59:53 pm »
Code: Bash  [Select][+][-]
  1. echo "const RevisionStr = 'main_3_99-2065-g520eccce1a';" > ide/revision.inc
  2. gmake bigide USESVN2REVISIONINC=0
This did the trick, thank you. Lazarus has been succesfully compiled. However, when i try to run it via startlazarus
Code: [Select]
(startlazarus:30167): GLib-GObject-CRITICAL **: 19:55:19.959: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
An unhandled exception occurred at $00000F967F379602:
EAccessViolation:
  $00000F967F379602 line 177 of /usr/src/lib/libc/stdlib/atexit.c
  $00000F967F37F7F5 line 54 of /usr/src/lib/libc/stdlib/exit.c
  $00000F939980D3A3  _FPC_PROC_HALTPROC,  line 72 of x86_64/si_c.inc
  $00000F939981F7C1  DOUNHANDLEDEXCEPTION,  line 144 of ../inc/except.inc
  $00000F939981F7C1  DOUNHANDLEDEXCEPTION,  line 144 of ../inc/except.inc
  $00000F939986271A  CREATEWIDGETSET,  line 2358 of forms.pp
  $00000F93998326F3  INTERFACES_$$_init$,  line 35 of interfaces.pas
or lazarus
Code: [Select]
(lazarus:35995): GLib-GObject-CRITICAL **: 19:55:31.315: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
An unhandled exception occurred at $00000ADA04526602:
EAccessViolation:
An unhandled exception occurred at $00000AD711B89AC0:
EAccessViolation:
  $00000AD711B89AC0
  $00000AD711B94A92
  $00000AD711B84901
  $00000AD711B84901
  $00000AD711BCC24A
  $00000AD711BC73A3
I did not installed it, i tried to run it from the directory it was compiled. But that should not make a difference, right?
« Last Edit: June 11, 2024, 06:05:17 pm by TCH »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #33 on: June 11, 2024, 09:28:55 pm »
It should not segfault at all. It seems the initialization of GTK/glib segfaults.

What was the traceback in GDB?

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #34 on: June 11, 2024, 11:18:22 pm »
For startlazarus:
Code: [Select]
GNU 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.
0x00000d9166d1339b in hb_font_t::mults_changed () from /usr/local/lib/libharfbuzz.so.18.7
And for lazarus:
Code: [Select]
GNU 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.
0x00000aede764b39b in hb_font_t::mults_changed () from /usr/local/lib/libharfbuzz.so.18.7
This is the function where the floating point exception happens (division by zero?): https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.hh#L689
However, i've just compared this file from harfbuzz 8.2.1 and 8.3.0 and there are no differences. This rules out Lazarus using the new harfbuzz erroneously, right? Except maybe, if the ABI has changed...but then why did the old 8.2.1 harfbuzz work with the new 7.5 kernel?
« Last Edit: June 11, 2024, 11:25:06 pm by TCH »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #35 on: June 12, 2024, 10:10:10 am »
Floating point exceptions are generally enabled in FPC programs, but sometimes other libraries silence them. ABI wise this is a grey area, it is best to simply always check for zero before dividing, in any language (cheaper than the exception anyway)

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #36 on: June 12, 2024, 11:52:25 am »
I agree, i always check for it too (if i don't forget it). But what can we do with this now?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #37 on: June 12, 2024, 01:37:50 pm »
Fix it or use setexceptionmask to inhibit exceptions. But that is an hack and a lazarus modification.

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #38 on: June 12, 2024, 02:43:05 pm »
I have no idea how to do that. I am only developing in FreePascal/Lazaurs, not developing it. Where to look? What to look for?
Besides, it is still not clear to me, what causes the error. My already built Lazarus 2.2.6 works with harfbuzz 8.2.1, but crashes with harfbuzz 8.3.0. The gdb-indicated function in harfbuzz did not change between 8.2.1 and 8.3.0 and the already built Lazarus 2.2.6 had obviously did not change.
Where does the error happening? In harfbuzz? In Lazarus?

I think i'll wait for FreePascal 3.2.4. I read it is only one issue away from releasing.
« Last Edit: June 12, 2024, 02:47:08 pm by TCH »

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1781
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #39 on: June 12, 2024, 03:39:54 pm »
Additional info.
Building FPC fixes or trunk with a 3.2.2 bootstrappers also fails on my 7.5 AMD64 system.
Fresh ppc1 binary works 99% until end: sigseg in the exit.

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #40 on: June 12, 2024, 04:49:43 pm »
Is there an open bugticket for this?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #41 on: June 12, 2024, 05:48:35 pm »
Don't know, but since there is no maintainer, one could argue the use.

OpenBSD has lived from external contributions in the last few years.

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #42 on: June 12, 2024, 06:07:25 pm »
I see. So, it is unlikely, that 3.2.4, or even 3.4.0 will fix these problems.

TCH

  • Full Member
  • ***
  • Posts: 243
    • Oldschool computer
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #43 on: June 12, 2024, 07:14:51 pm »
I tried to find the problematic harfbuzz part in Lazarus, but when i did a grep for the string 'harfbuzz', only two files were found: one is lazharfbuzz0.pas which has the bindings themselves to the lib and the other is lazpango1.pas, which calls in LazHarfBuzz0 in the uses list of the unit's interface section, but after that, it is not even used (as far as i could tell).

Also, these were among the gtk3 bindings, which is really weird, as Lazarus uses gtk2, does not it?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11935
  • FPC developer.
Re: Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5
« Reply #44 on: June 12, 2024, 07:19:29 pm »
I see. So, it is unlikely, that 3.2.4, or even 3.4.0 will fix these problems.

Well, "these problems" is vague, but the change rate of OpenBSD is glacial atm, and depends on random external contributions.

It was effectively dead, when some guy submitted some patches to turn it into a libc port. But I haven't seen new patches in a while.

Like FreeBSD, the LLVM changes might have an profound impact, as the LLVM binaries are less suitable (read: stable outside the very narrow area stressed by the corresponding C compiler) than the GCC ones.

Even on FreeBSD, we still use ld.bfd.

 

TinyPortal © 2005-2018