New extension llvm-lib for piCore64 breaks something in Xorg.

[mortegai]

When the llvm-lib extension is updated, the following changes occur in Xorg (excerpts from Xorg.0.log).

With older llvm-lib (version 10.0.0 by Juanito):

Code: [Select]

[    24.357] (II) Loading sub module "glamoregl"
[    24.357] (II) LoadModule: "glamoregl"
[    24.357] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[    24.373] (II) Module glamoregl: vendor="X.Org Foundation"
[    24.373] compiled for 1.20.8, module version = 1.0.1
[    24.373] ABI class: X.Org ANSI C Emulation, version 0.4
[    25.443] (II) modeset(0): glamor X acceleration enabled on V3D 4.2
[    25.443] (II) modeset(0): glamor initialized
....
[    25.673] (II) modeset(0): [DRI2] Setup complete
[    25.673] (II) modeset(0): [DRI2]   DRI driver: vc4
[    25.673] (II) modeset(0): [DRI2]   VDPAU driver: vc4
....
[    25.677] (II) Initializing extension GLX
[    25.757] (II) AIGLX: Loaded and initialized vc4
[    25.757] (II) GLX: Initialized DRI2 GL provider for screen 0

With new version (version 13.0.1 by polikuo):

Code: [Select]

[    26.395] (II) Loading sub module "glamoregl"
[    26.395] (II) LoadModule: "glamoregl"
[    26.396] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[    26.411] (II) Module glamoregl: vendor="X.Org Foundation"
[    26.411] compiled for 1.20.8, module version = 1.0.1
[    26.411] ABI class: X.Org ANSI C Emulation, version 0.4
[    26.425] couldn't get display device
[    26.425] (EE) modeset(0): glamor initialization failed
[    26.425] (II) modeset(0): ShadowFB: preferred NO, enabled NO
.....
[    26.532] (II) Initializing extension GLX
[    26.532] (II) AIGLX: Screen 0 is not DRI2 capable
[    26.532] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (/usr/local/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[    26.532] (EE) AIGLX error: unable to load driver swrast
[    26.532] (EE) GLX: could not load software renderer
[    26.532] (II) GLX: no usable GL providers found for screen 0


[polikuo]

Hi mortegai.

I can start Xorg just fine.

What extensions are you using ?
Which Pi are you using ?

This is my onboot.lst running on pi4B, 5.10.77-piCore-v8.

Code: [Select]

mylocale.tcz
firmware-rpi-wifi.tcz
wifi.tcz
unifont.tcz
openssh.tcz
aterm.tcz
wbar.tcz
alsa.tcz
alsa-utils.tcz
firefox.tcz
Xorg.tcz
openbox-config.tcz
openbox-locale.tcz

I can't find anything related to glamoregl in my Xorg.0.log

Code: [Select]

[    22.476] (II) Initializing extension GLX
[    22.476] (II) AIGLX: Screen 0 is not DRI2 capable
[    22.476] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (/usr/local/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[    22.476] (EE) AIGLX error: unable to load driver swrast
[    22.476] (EE) GLX: could not load software renderer
[    22.476] (II) GLX: no usable GL providers found for screen 0


[mortegai]

Yes, Xorg starts and works, but without hardware acceleration (as you can also see in your log).

My Pi is 4B with 4G, 5-10-77-piCore-v8, dtoverlay=vc4-kms-v3d in config.txt and with this onboot.lst:

Code: [Select]

mylocale.tcz
firmware-rpi-wifi
wpa_supplicant.tcz
openssh.tcz
squashfs-tools.tcz
file.tcz
x11vnc.tcz
firefox.tcz
wbar.tcz
rxvt.tcz
jwm.tcz
Xorg-3d.tcz


[Juanito]

Try loading llvm10-lib

[polikuo]

Try loading llvm10-lib

And update your deps

Code: [Select]

tce-audit updatedeps

[mortegai]

OK, going back to the previous version (with new name) everything works correctly again.

[mortegai]

Just as mesa.tcz depends on llvm10.tcz, shouldn't mesa-dev.tcz also depend on an llvm10-dev.tcz extension?

To avoid possible problems in the build of programs that depend on mesa and/or llvm.

[Juanito]

The idea is to discourage users from building against old versions of the llvm extension.

[mortegai]

I understand the idea, but
Can't it cause problems to build a program against the definitions and libraries of llvm v.13.0.1 and then at runtime mesa.tcz load the llvm v.10.0.0 libraries?

[Juanito]

I don’t believe so, at runtime mesa will use llvm-10 libs and the new app will use llvm-13 libs.

You would need to make sure that libLLVM.so points to the llvm-13 lib at compile time - i.e. load llvm-lib before llvm10-lib.