Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5

[TCH]

Or maybe not, because even if the GTK3 version runs, nothing works and nothing is visible in my app...

I tried to compile my project for Qt5, but libQt5Pas is not compilable: it dies because "expected unqualified-id" and without that, it is impossible to build for Qt5 with Lazarus.
And Qt4 or GTK1 is not available on OpenBSD.

Any ideas how to breathe life into libQt5Pas? Or to build without it? AFAIK only Lazarus 3.0 and above needs it, so i don't understand why Lazarus 2.2.6 complains that there is no -lQt5Pas...

[Fred vS]

Hello TCH.

Many thanks for your hard work and exploration.
We now have many more clues.

Do all these problems only appear with OpenBSD 7.5?
Was OpenBSD 7.4 allowed to run LCL applications with GTK2?

To summarize what I get:
I have OpenBSD 7.0 and fpc 3.2.2 produces working MSEgui applications for OpenBSD 7.5. Also.
But the same fpc 3.2.2 on OpenBSD 7.5 produces applications that don't work, even a simple "Hello world" console program.

I haven't tried with other versions of OpenBSD but if the problems only appear with OpenBSD 7.5 (and OpenBSD 7.4 was ok), we have a better chance of targeting the problem. And then create an issue with OpenBSD developers,

[TCH]

No problem, i also got a lot of help here.

These problems only appear with harfbuzz 8.3.0, not OpenBSD 7.5. When i do sysupgrade on 7.4 and it upgrades to 7.5, GTK2 Lazarus and the built apps (GTK2 too) still work. The problem only occurs, when i upgrade harfbuzz from 8.2.1 to 8.3.0, either by pkg_add -u as described in the OpenBSD upgrade manual, or if i do it by hand (pkg_add -u harfbuzz).

Here is an empty form application built with Lazarus 2.2.6 on OpenBSD 7.4 (with GTK2 widgetset and debug symbols): http://oscomp.hu/depot/project1-gtk2
This works on OpenBSD 7.5 too, until harfbuzz is updated.

As for the compiler not being able to create even a hello world, that is a different case; at my VM the compiler "works" (segfaults in particular cases) and it produces "working" programs. But i can imagine OpenBSD 7.5 itself being problematic, for instance syscall() being replaced to pinsyscalls(), which means a lot of stuff could be affected and changed in libc and FreePascal is not aware of that.

Any ideas on building Qt5 apps with Lazarus on OpenBSD or why libQt5Pas can not be compiled?

[TRon]

These problems only appear with harfbuzz 8.3.0, not OpenBSD 7.5. When i do sysupgrade on 7.4 and it upgrades to 7.5, GTK2 Lazarus and the built apps (GTK2 too) still work. The problem only occurs, when i upgrade harfbuzz from 8.2.1 to 8.3.0, either by pkg_add -u as described in the OpenBSD upgrade manual, or if i do it by hand (pkg_add -u harfbuzz).

Thank you very much for having figured that out and reported that here TCH.

That might be a potential issue for other platforms as well. My linux distro is using the whopping up-to-date version of libharfbuzz 6.0.0 (and I use a semi-rolling distro based on debian)

[Fred vS]

hese problems only appear with harfbuzz 8.3.0, not OpenBSD 7.5. When i do sysupgrade on 7.4 and it upgrades to 7.5, GTK2 Lazarus and the built apps (GTK2 too) still work. The problem only occurs, when i upgrade harfbuzz from 8.2.1 to 8.3.0,

OK, perfect, we know alsready that harfbuzz cause problem.

But, on OpenBSD 7.5, compiling a simple "Hello world" that has only libc as dependencies crash the app.
And strangely a app linked with libc.so.96.2 works on OpenBSD 7.5. (via a link to  libc.so.99.0   ).

On my OpenBSD 7.5., there is only one libc.so: libc.so.99.0 and a app linked with that version does not work.
So there are problems with libc too.

[TRon]

So there are problems with libc too.

Just for your information, there are known libc problems. Applications compiled on newer systems (depending on libc) do not run (anymore) on older systems for example aka libc versioning issues.

The situation as you described seems to be something new (unless I misunderstood)

[Fred vS]

So there are problems with libc too.

Just for your information, there are known libc problems. Applications compiled on newer systems (depending on libc) do not run (anymore) on older systems for example aka libc versioning issues.

Yes I know. 
But here the solution lies elsewhere because OpenBSD develops its own libc, without using signed symbol tables to ensure backward compatibility.
Other Unix operating systems use a single libc.so.6 with all previous symbol tables and new ones that can be used and assigned for each method at compile time. When known and used, it is wonderful.
With OpenBSD, each new feature has a new libc.so number, without symbol tables.

[TRon]

Yes I know. 

Ok, ok. Just checking 

I have to call defeat on your explanation(s) as I know next to nothing about (open)bsd. I do take your notes to heart though so thank you for that.

[Fred vS]

Yes I know. 

Ok, ok. Just checking 

I have to call defeat on your explanation(s) as I know next to nothing about (open)bsd. I do take your notes to heart though so thank you for that.

Same for me, it is a new jungle.
What attracted me is that for each new release, they compose and offer a song.
https://www.openbsd.org/lyrics.html
(But it seems that the last two are missing...  )

Conclusion: release without song is bad release.

[TRon]

Conclusion: release without song is bad release.

Haha... I did not even knew that.

Let me make a suggestion for them then... 

[TCH]

I wanted to try out one last thing: what if i downgrade or upgrade harfbuzz manually. I've compiled 8.2.1, 8.3.1 and 8.5.0 and copied only the problematic library (libharfbuzz.so), replacing the one in my system. Well, still crashed, but differently. It did not matter if i downgraded to 8.2.1 or upgraded it, crash:

Code: [Select]

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

Program received signal SIGFPE, Arithmetic exception.
[Switching to thread 410223]
0x000001a26851d0ae in FcCompare (pat=0x1a213e6f820, fnt=0x1a2d79268c8, value=0x1a2da896c08, result=0x1a2a3d24e98, data=0x1a2a3d24df8)
    at /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcmatch.c:645
645     /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcmatch.c: No such file or directory.
        in /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcmatch.c
Current language:  auto; currently minimal
(gdb) step
[FORMS.PP] ExceptionOccurred

Program received signal SIGFPE, Arithmetic exception.
[Switching to thread 557081]
_libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:29
29      /usr/src/lib/libc/string/strlcpy.c: No such file or directory.
        in /usr/src/lib/libc/string/strlcpy.c
(gdb) step
[FORMS.PP] ExceptionOccurred
[FORMS.PP] ExceptionOccurred
  Sender=EDivByZero
  Exception=Division by zero
  Stack trace:

Program received signal SIGFPE, Arithmetic exception.
[Switching to thread 410223]
_thread_sys_write () at /tmp/-:3
3       /tmp/-: No such file or directory.
        in /tmp/-
Current language:  auto; currently asm
(gdb) step

Program received signal SIGFPE, Arithmetic exception.
[Switching to thread 557081]
_thread_sys_read () at /tmp/-:3
3       /tmp/-: No such file or directory.
        in /tmp/-
(gdb) step
  $000001A29D934E10
  $000001A29D998D5D
  $000001A29D9971C1
  $000001A29D99737D
  $000001A2A2891F93
  $000001A2A28C220C
  $000001A2A28C29E0
  $000001A2A28C1CD1
  $000001A2A28C127F
  $000001A2A28C0B85
  $000001A2A28C06F2
  $000001A2A28C0255
  $000001A00A46707D
  $000001A00A466F40
  $000001A00A44201A
  $000001A00A440E83
Die: DW_TAG_set_type (abbrev = 36, offset = 1173321)
        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: 1173344 (adjusted)
Dwarf Error: Cannot find type of die [in module /root/project1-gtk2]If i done a full install (gmake install), then it was the same as before: the mults_changed() function. (Did not try this with upgrade too, but i doubt it would be different.) Something else too got wrong, besides harfbuzz. Or it is not harfbuzz at all, it is just "happening" in harfbuzz.

Any ideas how to build Qt5 apps with Lazarus 2.2.6? Or how to make libQt5Pas work? Currently i'd be content with that as a workaround.

[Fred vS]

I wanted to try out one last thing: what if i downgrade or upgrade harfbuzz manually. I've compiled 8.2.1, 8.3.1 and 8.5.0 and copied only the problematic library (libharfbuzz.so), replacing the one in my system. Well, still crashed, but differently. It did not matter if i downgraded to 8.2.1 or upgraded it, crash

It could be also one of his dependencies (see picture).

Any ideas how to build Qt5 apps with Lazarus 2.2.6? Or how to make libQt5Pas work? Currently i'd be content with that as a workaround.

Sorry but I cannot help for this. (I switched to MSEgui because of those dependencies problems.  )

But, imho, if you need to compile your Lazarus apps on a other system than OpenBSD 7.5, personally I would experiment with fpcupdeluxe and cross-compile using his Lazarus configured with the cross-compiler amd64-Linux --> amd64-OpenBSD.

And then you may play using other libraries replacing those from /fpcupdeluxe/cross/lib/x86_64-openbsd/ and this without to risk to damage your OpenBSD machine.

[TCH]

It could be also one of his dependencies (see picture).

Then the most likely candidate is glib. When i tried to step the crashed program, the next lib which reported SIGSEGV, was glib.

Sorry but I cannot help for this. (I switched to MSEgui because of those dependencies problems.  )

But, imho, if you need to compile your Lazarus apps on a other system than OpenBSD 7.5, personally I would experiment with fpcupdeluxe and cross-compile using his Lazarus configured with the cross-compiler amd64-Linux --> amd64-OpenBSD.

And then you may play using other libraries replacing those from /fpcupdeluxe/cross/lib/x86_64-openbsd/ and this without to risk to damage your OpenBSD machine.

Well, i installed FPC 3.2.2 and Lazarus 2.2.6 and added the cross-compiling option for OpenBSD/AMD64. It works, even for Lazarus apps, but if i try to build with Qt5 as the target widgetset, then the result is the same:

Code: [Select]

Error: /root/fpcupdeluxe/fpcupdeluxe/cross/bin/x86_64-openbsd/x86_64-openbsd-ld.bfd: cannot find -lQt5Pas

[marcov]

But, on OpenBSD 7.5, compiling a simple "Hello world" that has only libc as dependencies crash the app.
And strangely a app linked with libc.so.96.2 works on OpenBSD 7.5. (via a link to  libc.so.99.0   ).

On my OpenBSD 7.5., there is only one libc.so: libc.so.99.0 and a app linked with that version does not work.
So there are problems with libc too.

Are both linked on the same system? It might be that externally linked openbsd binaries have version markings from the cross compilation setup, while the on system generated binaries have 7.5 version info/ident.

IIRC with elfdump -n you can see the note with the version info

[TCH]

I've tried to compile libQt5Pas 1.2.15 again on OpenBSD 7.5.

qmake-qt5:

Code: [Select]

Project MESSAGE: Note: This binding version was generated for Qt 5.6.1. Current Qt is 5.15.12
Project MESSAGE: Qt documents binary compatibility in each Version Change Note: http://qt.nokia.com/developer/changes
Project MESSAGE: Adding x11extras for XOrg platform.
Project MESSAGE: Pascal Qt Interface for binding platform: BINUX
Project MESSAGE: Install location: /usr/local/lib/qt5I don't know what is BINUX, but it is OpenBSD.

gmake:

Code: [Select]

c++ -c -pipe -Wfatal-errors -w -pthread -fPIC -DBINUX -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB  -I. -I/usr/local/include/X11/qt5 -I/usr/local/include/X11/qt5/QtPrintSupport -I/usr/local/include/X11/qt5/QtWidgets -I/usr/local/include/X11/qt5/QtX11Extras -I/usr/local/include/X11/qt5/QtGui -I/usr/local/include/X11/qt5/QtNetwork -I/usr/local/include/X11/qt5/QtCore -Itmp -I/usr/X11R6/include -I/usr/X11R6/include/libdrm -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/openbsd-clang -o tmp/qobject_hook_c.o src/qobject_hook_c.cpp
In file included from src/qobject_hook_c.cpp:12:
In file included from src/qobject_hook_c.h:15:
In file included from src/qobject_hook.h:17:
In file included from /usr/local/include/X11/qt5/QtCore/qobject.h:46:
In file included from /usr/local/include/X11/qt5/QtCore/qobjectdefs.h:48:
In file included from /usr/local/include/X11/qt5/QtCore/qnamespace.h:43:
In file included from /usr/local/include/X11/qt5/QtCore/qglobal.h:45:
In file included from /usr/include/c++/v1/type_traits:421:
In file included from /usr/include/c++/v1/__functional/invoke.h:15:
In file included from /usr/include/c++/v1/__type_traits/apply_cv.h:15:
In file included from /usr/include/c++/v1/__type_traits/remove_reference.h:13:
In file included from /usr/include/c++/v1/cstddef:41:
./version:1:1: fatal error: expected unqualified-id
1.2.14
^
1 error generated.
gmake: *** [Makefile:2921: tmp/qobject_hook_c.o] Error 1Yes, the version file contains 1.2.14, while it is 1.2.15. But that is not the problem: older versions contains correct version strings and still got this error. Correcting it only yields the same error message but with the new version string.