|Summary:||x11-base/xorg-server 1.16.4 with musl and nouveau - error relocating nouveau_drv.so|
|Product:||Gentoo Linux||Reporter:||tt_1 <herrtimson>|
|Component:||[OLD] Unspecified||Assignee:||Gentoo musl team <musl>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Xorg.0.log reporting errors
Description tt_1 2015-05-03 10:49:44 UTC
Created attachment 402508 [details] Xorg.0.log reporting errors I emerged the xorg-server-1.16.4-r99 ebuild from the hardened-development overlay, which compiled fine. But when booting and typing either startx or startxfce4, there are errors concerning that certain .so files cannot be loaded or that there are symbol errors (?) [ 132.427] (II) LoadModule: "nouveau" [ 132.428] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [ 132.428] (EE) Failed to load /usr/lib/xorg/modules/drivers/nouveau_drv.so: Error relocating /usr/lib/xorg/modules/drivers/nouveau_drv.so: wfbScreenInit: symbol not found [ 132.428] (II) UnloadModule: "nouveau" [ 132.428] (II) Unloading nouveau [ 132.428] (EE) Failed to load module "nouveau" (loader failed, 7) I will attach my kernel.config and the full xorg.0.log
Comment 3 Felix Janda 2015-05-03 11:43:08 UTC
That is because xorg's module loading relies on lazy binding which musl does not support http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Lazy_bindings Try out if dropping http://git.alpinelinux.org/cgit/aports/tree/main/xorg-server/20-modules.conf as xorg.conf into /etc/X11 helps. (Assuming that you don't already have an xorg.conf file.)
Comment 4 Anthony Basile 2015-05-03 12:48:11 UTC
(In reply to Felix Janda from comment #3) > That is because xorg's module loading relies on lazy binding which musl > does not support > > http://wiki.musl-libc.org/wiki/ > Functional_differences_from_glibc#Lazy_bindings > > > Try out if dropping > > http://git.alpinelinux.org/cgit/aports/tree/main/xorg-server/20-modules.conf > > as xorg.conf into /etc/X11 helps. (Assuming that you don't already have an > xorg.conf file.) Correct, its the lazy binding. How should we deal with this in general? I know alpine's module ordering works for nouveau, but does it work in general?
Comment 5 Felix Janda 2015-05-03 14:00:34 UTC
Their 20-modules.conf works also for my intel setup. Actually the minimum I need is Section "Module" Load "int10" # no deps Load "vbe" # depends on int10 Load "fb" # no deps Load "shadowfb" # no deps Load "vgahw" # no deps EndSection The important thing is really only that the modules are loaded in the right order. The problem is also very similar to https://bugs.gentoo.org/show_bug.cgi?id=488906 but for us -Wl,z,lazy won't help. So, let the xorg-server ebuild install an /etc/X11/xorg.conf.d/20-modules.conf?
Comment 6 tt_1 2015-05-04 07:54:31 UTC
the proposed 20-modules.conf from the alpine repos does not work for me, unfortunatly. which modules would nouveau need?
Comment 7 Felix Janda 2015-05-04 14:53:10 UTC
You need to put 20-modules.conf into /etc/X11/xorg.conf.d (or rename it to xorg.conf). If that not doesn't work at least the error message must have changed. (-> upload the new Xorg.0.log) All relevant modules are in /usr/lib/xorg/modules/ from the error message it is not difficult to guess which module has the missing symbols.
Comment 8 tt_1 2015-05-04 17:24:00 UTC
so, if I do nm -D /usr/lib/xorg/modules/libwfb.so | grep wfbScreenInit the output is 0002b720 T wfbScreenInit does this mean that this is the missing piece and therefore I have to edit 20-modules.conf in a way that libwfb.so is loaded before the nouveau_drv.so? like this? Section "Module" Load "libwfb" Load "nouveau_drv" EndSection
Comment 9 Felix Janda 2015-05-04 18:41:20 UTC
You should leave out the 'lib'. "wfb" is however already in alpine linux' 20-modules.conf. So if you are using their file it should work or it should complain about some other missing symbols. Also you don't need to specify nouveau since it will be loaded automatically. (The problem is that xorg tries to load nouveau before wfb.)
Comment 10 Felix Janda 2017-10-21 01:51:27 UTC
With musl-1.1.17 this workaround should no longer be needed. Can you confirm?
Comment 11 tt_1 2017-12-02 21:41:03 UTC
Yes, this got fixed. Tested and confirmed with musl-1.1.18.