Nixpkgs: libEGL.so.1: undefined reference to `wl_proxy_*`

[danykey]

Issue description

I use nixos-unstable.
All pygtk dependents, for examples, keepnote, zim, deluge are crashes while starting.

[ERROR   ] 19:15:14 ui:168 /run/opengl-driver/lib/libEGL.so.1: undefined symbol: wl_proxy_marshal_constructor_versioned
Traceback (most recent call last):
  File "/nix/store/zdfdvrym0f600nm4y5x73hisrfcj672m-python2.7-deluge-1.3.12/lib/python2.7/site-packages/deluge/ui/ui.py", line 149, in __init__
    from deluge.ui.gtkui.gtkui import GtkUI
  File "/nix/store/zdfdvrym0f600nm4y5x73hisrfcj672m-python2.7-deluge-1.3.12/lib/python2.7/site-packages/deluge/ui/gtkui/__init__.py", line 1, in <module>
    from gtkui import start
  File "/nix/store/zdfdvrym0f600nm4y5x73hisrfcj672m-python2.7-deluge-1.3.12/lib/python2.7/site-packages/deluge/ui/gtkui/gtkui.py", line 50, in <module>
    reactor = gtk2reactor.install()
  File "/nix/store/7wimwv66ag4nra00x23cf949yj01y03w-python2.7-Twisted-15.5.0/lib/python2.7/site-packages/twisted/internet/gtk2reactor.py", line 99, in install
    reactor = Gtk2Reactor(useGtk)
  File "/nix/store/7wimwv66ag4nra00x23cf949yj01y03w-python2.7-Twisted-15.5.0/lib/python2.7/site-packages/twisted/internet/gtk2reactor.py", line 71, in __init__
    import gtk as _gtk
  File "/nix/store/3q4x6pp8686jb933h153ssf60zwx1pjh-python2.7-pygtk-2.24.0/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 40, in <module>
    from gtk import _gtk
ImportError: /run/opengl-driver/lib/libEGL.so.1: undefined symbol: wl_proxy_marshal_constructor_versioned

Steps to reproduce

Try run from nixos-unstable channel.

Technical details

• System: 16.09pre85931.125ffff (Flounder)
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: "16.09pre85931.125ffff"

[danykey]

I guess that this start happened after updating Mesa to 11.2.2

[FRidh]

I am running 65ac26e28a9191cb95410832e2272a1fe1d910e9 and just tested deluge and didn't encounter the issue. What video driver are you using? I use intel.

[danykey]

I use Intel also.

[    58.071] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20150731
...
[    58.080] (--) intel(0): Integrated Graphics Chipset: Intel(R) GM45

The kernel I have not switched:

Linux nixos 4.3.6 #1-NixOS SMP Fri Feb 19 22:35:24 UTC 2016 x86_64 GNU/Linux

Temporary I have rebooted to nixos-16.03 back.

[larkery]

This bug also affects some other packages; for example, taffybar produces

Error occurred while loading configuration file.
Error: /run/opengl-driver/lib/libEGL.so.1: undefined reference to `wl_proxy_get_version'
/run/opengl-driver/lib/libEGL.so.1: undefined reference to `wl_proxy_marshal_constructor_versioned'
collect2: error: ld returned 1 exit status

[FRidh]

@vcunat do you have any ideas what could cause this?

[vcunat]

A quick google found that updating wayland might solve the problem: https://forum.voidlinux.eu/t/solved-package-mpv-dependencies-seems-to-be-broken/422/2 EDIT: it's possible the problem is only caused by some combinations of nixpkgs and nixos versions.

[srhb]

pidgin and thunderbird are also affected by this on 16.09pre90254.6b20d5b (Flounder)

I'm not using Wayland.

[domenkozar]

Maybe fixed in https://github.com/NixOS/nixpkgs/commit/49d59ce0adf8397778ec3b9a36a149a66a013c88 ?

[vcunat]

No, that seems very unlikely to me.

[vcunat]

@Ptival: what's your nixos-version and from which version is your xfce4-terminal?

[Ptival]

nixos-version
16.09pre90254.6b20d5b (Flounder)

I believe it's xfce4-terminal-0.6.3.

[shlevy]

@domenkozar This seems serious enough to be a blocker, no?

[vcunat]

@Ptival: I mean, it's just the terminal from 6b20d5b and not one installed by nix-env? Also, it'll be good to know what videoDriver(s) you use. (The same's for anyone able to reproduce this.)

[vcunat]

The mesa's libEGL certainly seems to be linked correctly against high-enough wayland versions (I disregard 16.03 for this). These missing symbols have been present since wayland 1.10 which we have on master since April.

[Ptival]

@vcunat
Good catch! The xfce4-terminal was indeed in my user environment.

And it turns out, after running a:
nix-env -i xfce4-terminal -f /home/ptival/nixpkgs
xfce4-terminal started working again! (where nixpkgs was checked out at 6b20d5b)

Indeed the issue seemed to be that I had a different install of xfce4-terminal.

For the record:

configuration.nix: https://github.com/Ptival/config/blob/master/configuration.nix

As for my video drivers, I'm not sure, something Virtualbox-related, see here:

-- Logs begin at Tue 2016-08-02 11:25:34 PDT, end at Sun 2016-09-04 10:26:20 PDT. --
Sep 05 11:34:32 onyx systemd[1]: Starting X11 Server...
Sep 05 11:34:32 onyx systemd[1]: Started X11 Server.
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'xfce' - xfce
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'none + xmonad' - none + xmonad
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'xfce + xmonad' - xfce + xmonad
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'xfce' - xfce
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'none + xmonad' - none + xmonad
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/r2rw1zyiqlfpk7g0n092s9w07zmp959c-xsession 'xfce + xmonad' - xfce + xmonad
Sep 05 11:34:32 onyx display-manager[552]: /nix/store/qd3mcm6x4jj66jx10ni8g0fr92983dm8-xauth-1.0.9/bin/xauth:  file /var/run/slim.auth does not exist
Sep 05 11:34:32 onyx display-manager[552]: X.Org X Server 1.18.3
Sep 05 11:34:32 onyx display-manager[552]: Release Date: 2016-04-04
Sep 05 11:34:32 onyx display-manager[552]: X Protocol Version 11, Revision 0
Sep 05 11:34:32 onyx display-manager[552]: Build Operating System: Linux 4.4.14 x86_64
Sep 05 11:34:32 onyx display-manager[552]: Current Operating System: Linux onyx 4.4.19 #1-NixOS SMP Sat Aug 20 16:09:38 UTC 2016 x86_64
Sep 05 11:34:32 onyx display-manager[552]: Kernel command line: BOOT_IMAGE=(hd0,msdos1)/nix/store/q08yfi1604bbyl17q0iccy2mzb1q3854-linux-4.4.19/bzImage systemConfig=/nix/store/pq26cz5v2fqlk5kqz0nxldvdfx8bqr9q-nixos-system-onyx-16.09.git.6b20d5b init=/nix/store/pq26cz5v2fqlk5kqz0nxldvdfx8bqr9q-nixos-system-onyx-16.09.git.6b20d5b/init loglevel=4
Sep 05 11:34:32 onyx display-manager[552]: Build Date: 28 August 2016  12:16:05AM
Sep 05 11:34:32 onyx display-manager[552]:  
Sep 05 11:34:32 onyx display-manager[552]: Current version of pixman: 0.34.0
Sep 05 11:34:32 onyx display-manager[552]:         Before reporting problems, check http://wiki.x.org
Sep 05 11:34:32 onyx display-manager[552]:         to make sure that you have the latest version.
Sep 05 11:34:32 onyx display-manager[552]: Markers: (--) probed, (**) from config file, (==) default setting,
Sep 05 11:34:32 onyx display-manager[552]:         (++) from command line, (!!) notice, (II) informational,
Sep 05 11:34:32 onyx display-manager[552]:         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Sep 05 11:34:32 onyx display-manager[552]: (++) Log file: "/dev/null", Time: Mon Sep  5 11:34:32 2016
Sep 05 11:34:32 onyx display-manager[552]: (++) Using config file: "/nix/store/z9gnhhzwgzvqnjmzlzra3rm13m96sbqf-xserver.conf"
Sep 05 11:34:32 onyx display-manager[552]: (==) Using config directory: "/etc/X11/xorg.conf.d"
Sep 05 11:34:32 onyx display-manager[552]: (==) Using system config directory "/nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/share/X11/xorg.conf.d"
Sep 05 11:34:32 onyx display-manager[552]: (==) ServerLayout "Layout[all]"
Sep 05 11:34:32 onyx display-manager[552]: (**) |-->Screen "Screen-virtualbox[0]" (0)
Sep 05 11:34:32 onyx display-manager[552]: (**) |   |-->Monitor "<default monitor>"
Sep 05 11:34:32 onyx display-manager[552]: (**) |   |-->Device "Device-virtualbox[0]"
Sep 05 11:34:32 onyx display-manager[552]: (==) No monitor specified for screen "Screen-virtualbox[0]".
Sep 05 11:34:32 onyx display-manager[552]:         Using a default monitor configuration.
Sep 05 11:34:32 onyx display-manager[552]: (**) |-->Screen "Screen-modesetting[0]" (1)
Sep 05 11:34:32 onyx display-manager[552]: (**) |   |-->Monitor "<default monitor>"
Sep 05 11:34:32 onyx display-manager[552]: (**) |   |-->Device "Device-modesetting[0]"
Sep 05 11:34:32 onyx display-manager[552]: (==) No monitor specified for screen "Screen-modesetting[0]".
Sep 05 11:34:32 onyx display-manager[552]:         Using a default monitor configuration.
Sep 05 11:34:32 onyx display-manager[552]: (**) |-->Input Device "VBoxMouse"
Sep 05 11:34:32 onyx display-manager[552]: (**) Option "DontZap" "on"
Sep 05 11:34:32 onyx display-manager[552]: (**) Option "AllowMouseOpenFail" "on"
Sep 05 11:34:32 onyx display-manager[552]: (==) Automatically adding devices
Sep 05 11:34:32 onyx display-manager[552]: (==) Automatically enabling devices
Sep 05 11:34:32 onyx display-manager[552]: (==) Automatically adding GPU devices
Sep 05 11:34:32 onyx display-manager[552]: (==) Max clients allowed: 256, resource mask: 0x1fffff
Sep 05 11:34:32 onyx display-manager[552]: (**) FontPath set to:
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/bg9lxschbjrnmg00hkip83znipq5bw5k-font-bh-ttf-1.0.3/lib/X11/fonts/TTF,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/2rn7g4s45ypp7n1if378n4yyb5a5cg02-font-bh-lucidatypewriter-100dpi-1.0.3/lib/X11/fonts/100dpi,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/xgajx7a1snhc0yd9p5d86hm17n81ppcb-font-bh-lucidatypewriter-75dpi-1.0.3/lib/X11/fonts/75dpi,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/p34jd8a6kc6wgr3ivpggh27ndqa0fyx8-font-bh-100dpi-1.0.3/lib/X11/fonts/100dpi,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/4i5aid02p1kw886mirgfghlq8kaimnjv-font-misc-misc-1.1.2/lib/X11/fonts/misc,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/038asiair119icss9hnxjl11vhfybbpr-font-cursor-misc-1.0.3/lib/X11/fonts/misc,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/gqvv9ffp20hkwvqg820y84bfims35a86-unifont-9.0.01/share/fonts,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/w074lhslg8ng6sgfasfb0bws33bfr0w8-font-adobe-100dpi-1.0.3/lib/X11/fonts/100dpi,
Sep 05 11:34:32 onyx display-manager[552]:         /nix/store/grxq6j9vaz2bqx44zkyx33x6x67lq0y5-font-adobe-75dpi-1.0.3/lib/X11/fonts/75dpi
Sep 05 11:34:32 onyx display-manager[552]: (**) ModulePath set to "/nix/store/dzqpi4kgzjwhn3gn2fmal8haqvgdipgr-VirtualBox-GuestAdditions-5.0.26-4.4.19/lib,/nix/store/dzqpi4kgzjwhn3gn2fmal8haqvgdipgr-VirtualBox-GuestAdditions-5.0.26-4.4.19/lib/dri,/nix/store/dzqpi4kgzjwhn3gn2fmal8haqvgdipgr-VirtualBox-GuestAdditions-5.0.26-4.4.19/lib/xorg/modules/drivers,/nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/lib/xorg/modules,/nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/lib/xorg/modules/drivers,/nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/lib/xorg/modules/extensions,/nix/store/6iyqnds5ywhabyp1s409b16cj082rgll-xf86-input-evdev-2.10.2/lib/xorg/modules/input"
Sep 05 11:34:32 onyx display-manager[552]: (II) The server relies on udev to provide the list of input devices.
Sep 05 11:34:32 onyx display-manager[552]:         If no devices become available, reconfigure udev or disable AutoAddDevices.
Sep 05 11:34:32 onyx display-manager[552]: (II) Loader magic: 0x819d00
Sep 05 11:34:32 onyx display-manager[552]: (II) Module ABI versions:
Sep 05 11:34:32 onyx display-manager[552]:         X.Org ANSI C Emulation: 0.4
Sep 05 11:34:32 onyx display-manager[552]:         X.Org Video Driver: 20.0
Sep 05 11:34:32 onyx display-manager[552]:         X.Org XInput driver : 22.1
Sep 05 11:34:32 onyx display-manager[552]:         X.Org Server Extension : 9.0
Sep 05 11:34:32 onyx display-manager[552]: (++) using VT number 7
Sep 05 11:34:32 onyx display-manager[552]: (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
Sep 05 11:34:32 onyx display-manager[552]: (--) PCI:*(0:0:2:0) 80ee:beef:0000:0000 rev 0, Mem @ 0xe0000000/134217728
Sep 05 11:34:32 onyx display-manager[552]: (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
Sep 05 11:34:32 onyx display-manager[552]: (II) "glx" will be loaded by default.
Sep 05 11:34:32 onyx display-manager[552]: (II) LoadModule: "glx"
Sep 02 11:33:19 onyx display-manager[552]: (II) Loading /nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/lib/xorg/modules/extensions/libglx.so
Sep 02 11:33:19 onyx display-manager[552]: (II) Module glx: vendor="X.Org Foundation"
Sep 02 11:33:19 onyx display-manager[552]:         compiled for 1.18.3, module version = 1.0.0
Sep 02 11:33:19 onyx display-manager[552]:         ABI class: X.Org Server Extension, version 9.0
Sep 02 11:33:19 onyx display-manager[552]: (==) AIGLX enabled
Sep 02 11:33:19 onyx display-manager[552]: (II) LoadModule: "vboxvideo"
Sep 02 11:33:19 onyx display-manager[552]: (II) Loading /nix/store/dzqpi4kgzjwhn3gn2fmal8haqvgdipgr-VirtualBox-GuestAdditions-5.0.26-4.4.19/lib/xorg/modules/drivers/vboxvideo_drv.so
Sep 02 11:33:19 onyx display-manager[552]: (II) Module vboxvideo: vendor="Oracle Corporation"
Sep 02 11:33:19 onyx display-manager[552]:         compiled for 1.18.0, module version = 1.0.1
Sep 02 11:33:19 onyx display-manager[552]:         Module class: X.Org Video Driver
Sep 02 11:33:19 onyx display-manager[552]:         ABI class: X.Org Video Driver, version 20.0
Sep 02 11:33:19 onyx display-manager[552]: (**) Load address of symbol "VBOXVIDEO" is 0x7ffba7e812e0
Sep 02 11:33:19 onyx display-manager[552]: (II) LoadModule: "modesetting"
Sep 02 11:33:19 onyx display-manager[552]: (II) Loading /nix/store/sxksyfzh5nqd03gvj9i79ibj1wfaf9zy-xorg-server-1.18.3/lib/xorg/modules/drivers/modesetting_drv.so
Sep 02 11:33:19 onyx display-manager[552]: (II) Module modesetting: vendor="X.Org Foundation"
Sep 02 11:33:19 onyx display-manager[552]:         compiled for 1.18.3, module version = 1.18.3
Sep 02 11:33:19 onyx display-manager[552]:         Module class: X.Org Video Driver
Sep 02 11:33:19 onyx display-manager[552]:         ABI class: X.Org Video Driver, version 20.0
Sep 02 11:33:19 onyx display-manager[552]: (II) LoadModule: "vboxmouse"
Sep 02 11:33:19 onyx display-manager[552]: (WW) Warning, couldn't open module vboxmouse
Sep 02 11:33:19 onyx display-manager[552]: (II) UnloadModule: "vboxmouse"
Sep 02 11:33:19 onyx display-manager[552]: (II) Unloading vboxmouse
Sep 02 11:33:19 onyx display-manager[552]: (EE) Failed to load module "vboxmouse" (module does not exist, 0)
Sep 02 11:33:19 onyx display-manager[552]: (II) VBoxVideo: guest driver for VirtualBox: vbox
Sep 02 11:33:19 onyx display-manager[552]: (II) modesetting: Driver for Modesetting Kernel Drivers: kms
Sep 02 11:33:20 onyx display-manager[552]: (WW) Falling back to old probe method for modesetting
Sep 02 11:33:20 onyx display-manager[552]: (EE) open /dev/dri/card0: No such file or directory
Sep 02 11:33:20 onyx display-manager[552]: (II) VBoxVideo(0): VirtualBox guest additions video driver version 5.0.26r108824
Sep 02 11:33:20 onyx display-manager[552]: (II) Loading sub module "ramdac"
Sep 02 11:33:20 onyx display-manager[552]: (II) LoadModule: "ramdac"
Sep 02 11:33:20 onyx display-manager[552]: (II) Module "ramdac" already built-in
Sep 02 11:33:20 onyx display-manager[552]: (II) Loading sub module "fb"
Sep 02 11:33:20 onyx display-manager[552]: (II) LoadModule: "fb"
Sep 02 11:33:23 onyx systemd[1]: display-manager.service: Service hold-off time over, scheduling restart.
Sep 02 11:33:23 onyx systemd[1]: Stopped X11 Server.
Sep 02 11:33:23 onyx systemd[1]: Starting X11 Server...
Sep 02 11:33:23 onyx systemd[1]: Started X11 Server.

[dezgeg]

Probably the problem is that something else that the app depends on (looks like Pango in case of xfce4terminal) already pulls in the old version of libwayland into the process, which prevents loading of the libwayland that mesa wants.

I have no idea how that problem can be prevented.

[vcunat]

Updating as a work-around doesn't seem that bad. It must be from around 16.03 time, and I don't expect we'll support that one for longer than several weeks since now.

There may be some linker tweaks for this, but I don't know such details.

[remysucre]

Getting similar error from ghc-vis which depends on gtk3 as referenced above. Is that indeed relevant?

[mdorman]

@larkery (and maybe this applies to ghc-vis, @remysucre) at least for me, removing the "cached" taffybar executable (rm ~/.cache/taffybar/taffybar*) and letting it recompile took care of it for me.

[remysucre]

@mdorman nah I don't even have taffybar, and removing the entire .cache didn't do it either

[vcunat]

As @dezgeg noted, I think the problem happens when your executable uses libwayland_client from wayland < 1.10 and at the same time runs on recent NixOS (i.e. recent mesa in /run/opengl-driver).

You can check nix-store -qR $(which your-executable) | grep wayland to see the version (whether any at all). Notably, we still have wayland 1.9.0 on the current stable 16.03.

[remysucre]

@vcunat I did find both wayland and 1.9 1.11 in /nix/store, however I'm not sure how ghc-vis is using it or which one it's using since it's a library not a executable (i.e. I just cd'ed into /nix/store then grep'ed). I'm also using nixpkg head right now. What would you recommend to do?

[vcunat]

@remysucre: I would either downgrade NixOS to 16.03 or upgrade ghc-vis-related packages to unstable/master/16.09 so that both were consistent wrt. this wayland version difference. The nix-store -qR command works on any files, not just executables.

[remysucre]

@vcunat upgrading nixos to unstable fixed it (I had nixpkgs master but fogot about nixos itself)! Thanks a lot.

[rzetterberg]

I encounter this problem with firefox on NixOS unstable 16.09pre90254.6b20d5b (Flounder).

Sep 09 08:22:19 rz xsession[1009]: XPCOMGlueLoad error for file /nix/store/0zd2d6kb0mdyc5kkwar1dlafjr2hbyv1-firefox-unwrapped-46.0.1/lib/firefox-46.0.1/libxul.so:
Sep 09 08:22:19 rz xsession[1009]: /run/opengl-driver/lib/libEGL.so.1: undefined symbol: wl_proxy_marshal_constructor_versioned
Sep 09 08:22:19 rz xsession[1009]: Couldn't load XPCOM.

[shlevy]

I had this problem when I upgraded nixos but didn't upgrade chromium. I suspect packages linked against old versions of mesa (whether because they are static or because they are old) are the issue. I was able to work around it by unsetting LD_LIBRARY_PATH, but I guess this kind of thing is inherent in the /run/opengl-driver impurity.

[zimbatm]

It might be useful to find out what version of DRI X11 is using. glxinfo | grep DRI

[rzetterberg]

@shlevy Thank you! Doing nix-env -u solved all my problems I had with the undefined symbols. I always forget that you update those packages separately from the system packages.

[vcunat]

I'm not sure it's completely inherent. IIRC, gnu ld can be forced to ignore some symbols – consider them only private to some libraries, but I don't remember if one could apply such stuff in our case.

[dezgeg]

Maybe dlmopen looks like what we would want.

[vcunat]

Maybe. If we provided a set of dummy libGL.so libs that would load the corresponding mesa lib via dlmopen or similar calls and map the public mesa symbols into that namespace. That's still a bit nontrivial to implement, but realistic.

It's also possible that the new glvnd interface might make fixing this easier (my knowledge about that is very superficial ATM).

[domenkozar]

Is there anything we can do here for 16.09 except documenting that libs shouldn't be mixed?

[vcunat]

@domenkozar: it's very unlikely that I could manage to improve the situation before 16.09. It's a bit unfortunate situation, as it breaks one of the best nixpkgs features, and libGL and wayland are getting into more closures over time.

We might downgrade the version of wayland for now (for mesa at least) to work around this, though I don't know for sure it would really be an improvement overall.

[vcunat]

Hmm, right, I confirm that if the NixOS uses mesa_drivers built against wayland-1.9.0, this problem goes away both for programs built against old _and_ new wayland. I think such a setup might instead break use cases that rely on new libwayland* features, but I suppose that should be a minority, so we might risk that (but it's almost untested ATM).

[groxxda]

Can someone explain to me what the problem is, that's solved by the /run/opengl-drivers impurity?
Do we need this so we don't have to compile xorg etc for every driver we support (and so users of unfree drivers don't have to recompile everything their self)?

This is from the dependency graph for taffybar:

taffybar (-> ghc) -> cairo 0.13 -> cairo 1.14 -> fontconfig -> mesa_noglu -> wayland

• I update my NixOS, a new version of the mesa drivers is put into /run/opengl-drivers that is linked against wayland-1.10.
• I run an old taffybar (for example from my user environment, which I did not update yet).
• That taffybar has a (transitive) path for the old mesa and thus wayland-1.9 (LD_LIBRARY_PATH, right?).
• taffybar uses cairo -> fontconfig -> mesa
• mesa takes the opengl driver from /run/opengl-drivers (here the impurity happens)
• that opengl driver loads wayland-1.9 from taffybars path becaues it takes precedence over the one that (should?) be embedded in mesa
• since it was compiled against a newer wayland it fails because it can't resolve the new symbols

Is this approximately what happens or am I completely wrong?
Maybe we can document this impurity in the nixos manual..

I would be really thankful if someone sheds some light on this ( @vcunat @domenkozar @shlevy ?)

Also I really don't understand how the resurrect wayland 1.9 commit can change anything without changing mesa to use the old version.

[shlevy]

IIRC the impurity arises because you need a different library depending on your hardware, which is inherently a system-level concern. But I think a better approach could be found probably.

[edolstra]

I guess the easiest fix is to build Mesa without Wayland? That will also reduce the closure size of X11 apps a bit...

[groxxda]

@edolstra can we have a second path with wayland (and without x, if possible) that gets built by hydra? having to build the mesa closure if you want to use wayland is (at least) a bit frustrating :wink:

i'm not sure what will happen to xwayland, but I _assume_ it should work with a non-x mesa

also that wouldn't really fix the problem but make it less common since x does not move (so fast?) and not many people use wayland (yet)

[vcunat]

• IIRC the interface between libGL and the kernel driver is not fixed/stable; it's those libs that have well-defined ABI and they should be exchanged along with the kernel module.
• Resurrection of old wayland does nothing _by itself_ (I originally didn't intend to push it).
• It's not just about wayland. There are more libraries that "get exchanged" by this, only we haven't hit any problem yet AFAIK.

I'm not even certain it's best for mesa to use its own libs – it would mean e.g. having multiple libc versions used within a single process – I don't know if that can break some lib's assumptions.

[shlevy]

@vcunat Citation on your first point? I thought Linux was very strong on not having unstable ABIs, and that would absolutely include library/kernel ABI

[vcunat]

Unfortunately, I can't find any reference, and I don't remember if it was from any reliable source anyway. I assume it's about utilizing some vendor-specific stuff exposed by the kernel drivers.

[vcunat]

that opengl driver loads wayland-1.9 from taffybars path becaues it takes precedence over the one that (should?) be embedded in mesa

$LD_LIBRARY_PATH has precedence over RPATH. I think what happens is that taffybar first loads something that loads that library from wayland-1.9 and then it starts loading libEGL which sees that the wayland lib is already loaded so doesn't attempt re-loading it (and can't anyway since it's all the same namespace by default).

[domenkozar]

@vcunat can you add a changelog for 16.09 explaining the situation and what users can do to fix the issue?

[vcunat]

@domenkozar: given the amount of real nixos+wayland users, I'm seriously considering building the drivers against the old wayland for now by default – in 16.09 and perhaps in master as well (it's not even a mass-rebuild change).

[vcunat]

After more testing, I pushed that work-around to master and 16.09, until we have a better solution (which might take very long to appear). Please, report cases not fixed by this.

Real wayland users might be forced to override it back and avoid using packages from older nixpkgs.

[groxxda]

Shouldn't we set wayland = wayland_1_9 in all-packages.nix then?

This workaround has it's justification for 16.09 but I'm really sad seeing it in master.

[vcunat]

Many packages requiring newer wayland may work even with this change. Mesa doesn't mind when its wayland "gets updated" impurely, as the libraries are compatible in this way.

[domenkozar]

I have reverted this in 140f82a8d91ae8b778024d35df41414edeecbd74 on 16.09 to get the channel moving so we can do a release.

[matthiasbeyer]

truecrypt seems to be affected as well as reported in https://github.com/NixOS/nixpkgs/issues/19162

---

Unfortunately, truecrypt does not even yield help text when trying truecrypt --help. I tried truecrypt -t which should start truecrypt in text-mode, but that yields the same error as reported in the issue linked above.

[matthiasbeyer]

I just build truecrypt from master (all packages seem to be in the cache for this, I had no build actually) and truecrypt starts again.

[vcunat]

It's common that text-mode programs that do have a graphics mode also fail to start, as it's typical to resolve all libs during startup. I experience the problem with text-mode _vim_, for example.

[vcunat]

I'm now fairly confident that adopting libglvnd is the way to go; I'm looking into details ATM. I believe it will result into various GL-related improvements (including multi-vendor setups, non-NixOS, closure sizes, etc.). Some users report (slight) performance degradation, but I suppose we'll bear it and hope upstream will reduce that in future. EDIT: note that libglvnd is most likely far too big change to make it into 16.09.

[ocharles]

Should we close this? 16.09 is out, and this bug ended up making it to the release (I just updated, and everything in my ~ profile is broken and has required reinstalls).

[vcunat]

Well, the bug is still there. Some library update may trigger it again in future (and it's not just about wayland).

[offlinehacker]

Same bug on current nixpkgs unstable

[offlinehacker]

What is the current workaround?

[vcunat]

@offlinehacker: the easiest way is to use matching NixOS and nixpkgs versions (it's enough that they don't differ on wayland being >= 1.10).

[offlinehacker]

Ahh ok, makes sense, thx!

On Wed, Nov 16, 2016, 9:40 PM Vladimír Čunát [email protected]
wrote:

@offlinehacker https://github.com/offlinehacker: the easiest way is to
use matching NixOS and nixpkgs versions (it's enough that they don't differ
on wayland being >= 1.10).

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/16779#issuecomment-261064973,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjvS6vcX2CuC7YtFbHcnIXdmRePiX1gks5q-2oigaJpZM4JHQhE
.

[Rotsor]

So, what are the downsides to building Mesa without Wayland as a workaround? If that works, it seems better than the really invasive "upgrade everything" approach.

[vcunat]

@Rotsor: I don't know, but building the drivers against older wayland version should be enough to work around this, as I mentioned above. (You need to rebuild just the drivers, not everything depending on mesa.)

[Rotsor]

@vcunat yes, but that (apparently) breaks kde so it can't go into master, which is a shame. I was thinking that if mesa-without-wayland breaks fewer things (I have no idea) then it has a chance of going into master.

[peterhoeg]

Is this still an issue @danykey ?

[vcunat]

Well, we haven't sorted this out, really. The impurity hits us here, due to the fact that we want to load two arbitrary closures into a single process. For now I see no easy solution, except to avoid mixing "too different" versions for libGL runtime dependencies.

[dezgeg]

I created a higher-level bug to track the underlying problem: #31189, so closing this specific issue.