Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 548474

Summary: x11-base/xorg-server 1.16.4 with musl and nouveau - error relocating
Product: Gentoo Linux Reporter: tt_1 <herrtimson>
Component: [OLD] UnspecifiedAssignee: Gentoo musl team <musl>
Severity: normal CC: blueness, tsmksubc
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 430702    
Attachments: 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/
[   132.428] (EE) Failed to load /usr/lib/xorg/modules/drivers/ Error relocating /usr/lib/xorg/modules/drivers/ 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 1 tt_1 2015-05-03 10:51:15 UTC
Created attachment 402510 [details]
Comment 2 tt_1 2015-05-03 10:53:06 UTC
Created attachment 402512 [details]
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

Try out if dropping

as xorg.conf into /etc/X11 helps. (Assuming that you don't already have an
xorg.conf file.)
Comment 4 Anthony Basile gentoo-dev 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
> Functional_differences_from_glibc#Lazy_bindings
> Try out if dropping
> 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

The important thing is really only that the modules are loaded in the
right order.

The problem is also very similar to

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/ | 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 is loaded before the 

like this? 

Section "Module"

   Load "libwfb"
   Load "nouveau_drv" 

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
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.