libEGL.so.1: undefined reference to `wl_proxy_*` #16779

Open
danykey opened this Issue Jul 7, 2016 · 61 comments

Projects

None yet
@danykey
danykey commented Jul 7, 2016

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
danykey commented Jul 7, 2016

I guess that this start happened after updating Mesa to 11.2.2

@FRidh FRidh changed the title from nixos-unstable: all pygtk dependents crashes while starting: ImportError: /run/opengl-driver/lib/libEGL.so.1: undefined symbol: wl_proxy_marshal_constructor_versioned to nixos-unstable: all pygtk dependents crash while starting Jul 7, 2016
@FRidh
Member
FRidh commented Jul 12, 2016

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

@danykey
danykey commented Jul 12, 2016 edited

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
Contributor
larkery commented Jul 13, 2016

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
Member
FRidh commented Jul 29, 2016

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

@vcunat
Member
vcunat commented Jul 29, 2016 edited

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
Contributor
srhb commented Sep 1, 2016

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

I'm not using Wayland.

@domenkozar
Member

Maybe fixed in 49d59ce ?

@vcunat
Member
vcunat commented Sep 2, 2016

No, that seems very unlikely to me.

@vcunat
Member
vcunat commented Sep 2, 2016

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

@Ptival
Contributor
Ptival commented Sep 2, 2016
nixos-version
16.09pre90254.6b20d5b (Flounder)

I believe it's xfce4-terminal-0.6.3.

@domenkozar domenkozar added this to the 16.09 milestone Sep 2, 2016
@shlevy
Member
shlevy commented Sep 2, 2016

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

@vcunat
Member
vcunat commented Sep 2, 2016

@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 vcunat changed the title from nixos-unstable: all pygtk dependents crash while starting to libEGL.so.1: undefined reference to `wl_proxy_*` Sep 2, 2016
@vcunat
Member
vcunat commented Sep 2, 2016 edited

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
Contributor
Ptival commented Sep 2, 2016 edited

@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
Contributor
dezgeg commented Sep 2, 2016

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 vcunat added a commit that referenced this issue Sep 2, 2016
@vcunat vcunat wayland-protocols: 1.4 -> 1.7
/cc #16779; I'm confident this can't affect the problem,
but the update shouldn't hurt.
0d0465f
@vcunat
Member
vcunat commented Sep 2, 2016

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.

@vcunat vcunat referenced this issue Sep 4, 2016
@groxxda @fpletz groxxda + fpletz wayland-protocols: 1.4 -> 1.7
(cherry picked from commit 73a4a91)
5d46ddf
@remysucre

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

@mdorman
Contributor
mdorman commented Sep 5, 2016

@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
Member
vcunat commented Sep 5, 2016

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
remysucre commented Sep 5, 2016 edited

@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
Member
vcunat commented Sep 5, 2016

@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 rzetterberg referenced this issue Sep 9, 2016
Merged

slack: 2.1.0 -> 2.1.2 #18434

3 of 7 tasks complete
@rzetterberg
Contributor

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
Member
shlevy commented Sep 9, 2016

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
Contributor
zimbatm commented Sep 9, 2016

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

@rzetterberg
Contributor

@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
Member
vcunat commented Sep 9, 2016

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.

@FRidh FRidh removed the 6.topic: python label Sep 19, 2016
@dezgeg
Contributor
dezgeg commented Sep 19, 2016

Maybe dlmopen looks like what we would want.

@vcunat
Member
vcunat commented Sep 19, 2016

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
Member

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

@vcunat
Member
vcunat commented Sep 24, 2016

@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
Member
vcunat commented Sep 24, 2016

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

@vcunat vcunat added a commit that referenced this issue Sep 24, 2016
@vcunat vcunat wayland: resurrect version 1.9.0
It'll likely be useful because of #16779, at least for some users.
Most of the change sneaked in c68850c already, by mistake.
0593ad2
@vcunat vcunat added a commit that referenced this issue Sep 24, 2016
@vcunat vcunat wayland: resurrect version 1.9.0
It'll likely be useful because of #16779, at least for some users.
Most of the change sneaked in c68850c already, by mistake.

(cherry picked from commit 0593ad2)
0cba714
@groxxda
Contributor
groxxda commented Sep 27, 2016

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
Member
shlevy commented Sep 27, 2016

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
Member

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

@groxxda
Contributor
groxxda commented Sep 27, 2016 edited

@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 😉

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
Member
vcunat commented Sep 27, 2016
  • 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
Member
shlevy commented Sep 27, 2016

@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
Member
vcunat commented Sep 27, 2016

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
Member
vcunat commented Sep 27, 2016

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

@srhb srhb added a commit to srhb/nixpkgs that referenced this issue Sep 28, 2016
@vcunat @srhb vcunat + srhb wayland: resurrect version 1.9.0
It'll likely be useful because of #16779, at least for some users.
Most of the change sneaked in c68850c already, by mistake.
9c1d9e4
@domenkozar
Member

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

@vcunat
Member
vcunat commented Sep 28, 2016

@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 vcunat added a commit that referenced this issue Sep 28, 2016
@vcunat vcunat mesa_drivers: work around #16779
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.

(cherry picked from commit 7a003eb)
4cf7839
@vcunat vcunat added a commit that referenced this issue Sep 28, 2016
@vcunat vcunat mesa_drivers: work around #16779
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.
7a003eb
@vcunat
Member
vcunat commented Sep 28, 2016 edited

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
Contributor
groxxda commented Sep 28, 2016

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
Member
vcunat commented Sep 28, 2016

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.

@groxxda groxxda added a commit to groxxda/nixpkgs that referenced this issue Sep 29, 2016
@vcunat @groxxda vcunat + groxxda mesa_drivers: work around #16779
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.
4c013b4
@acowley acowley added a commit to acowley/nixpkgs that referenced this issue Sep 29, 2016
@vcunat @acowley vcunat + acowley wayland: resurrect version 1.9.0
It'll likely be useful because of #16779, at least for some users.
Most of the change sneaked in c68850c already, by mistake.
76b8a66
@acowley acowley added a commit to acowley/nixpkgs that referenced this issue Sep 29, 2016
@vcunat @acowley vcunat + acowley mesa_drivers: work around #16779
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.
5bbf1c2
@domenkozar
Member
domenkozar commented Oct 1, 2016 edited

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

@domenkozar domenkozar added a commit that referenced this issue Oct 1, 2016
@domenkozar domenkozar Revert "mesa_drivers: work around #16779"
This reverts commit 4cf7839.

Breaks kde5 test. http://hydra.nixos.org/build/41374761
140f82a
@domenkozar domenkozar added a commit that referenced this issue Oct 1, 2016
@domenkozar domenkozar document #16779 db6a20b
@matthiasbeyer
Contributor
matthiasbeyer commented Oct 2, 2016 edited

truecrypt seems to be affected as well as reported in #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
Contributor

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
Member
vcunat commented Oct 2, 2016

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
Member
vcunat commented Oct 2, 2016 edited

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.

@groxxda groxxda added a commit to groxxda/nixpkgs that referenced this issue Oct 2, 2016
@groxxda groxxda wayland: revert global version back to 1.9
This is a dirty fix for #16779 until we have a better way.
Only using the old wayland for mesa breaks stuff silently (for example
KDE).
b1c4cb3
@ttuegel ttuegel added a commit to ttuegel/nixpkgs that referenced this issue Oct 2, 2016
@ttuegel ttuegel Revert "mesa_drivers: work around #16779"
This reverts commit 7a003eb.
05938ca
@bramd bramd added a commit to bramd/nixpkgs that referenced this issue Oct 22, 2016
@vcunat @bramd vcunat + bramd mesa_drivers: work around #16779
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.

(cherry picked from commit 7a003eb)
fd318f5
@bramd bramd added a commit to bramd/nixpkgs that referenced this issue Oct 22, 2016
@domenkozar @bramd domenkozar + bramd Revert "mesa_drivers: work around #16779"
This reverts commit 4cf7839.

Breaks kde5 test. http://hydra.nixos.org/build/41374761
a742085
@bramd bramd added a commit to bramd/nixpkgs that referenced this issue Oct 22, 2016
@domenkozar @bramd domenkozar + bramd document #16779 4769f7c
@ocharles
Contributor
ocharles commented Nov 3, 2016

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
Member
vcunat commented Nov 3, 2016

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

@offlinehacker
Contributor

Same bug on current nixpkgs unstable

@offlinehacker
Contributor
offlinehacker commented Nov 16, 2016 edited

What is the current workaround?

@vcunat
Member
vcunat commented Nov 16, 2016

@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
Contributor

Ahh ok, makes sense, thx!

On Wed, Nov 16, 2016, 9:40 PM Vladimír Čunát notifications@github.com
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
#16779 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjvS6vcX2CuC7YtFbHcnIXdmRePiX1gks5q-2oigaJpZM4JHQhE
.

@dezgeg dezgeg referenced this issue Dec 28, 2016
Closed

sssd: init at 1.14.2 #21150

4 of 7 tasks complete
@Rotsor
Contributor
Rotsor commented Dec 30, 2016

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
Member
vcunat commented Dec 30, 2016

@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
Contributor
Rotsor commented Dec 31, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment