search

NVIDIA / tegra-nouveau-rootfs

Manifests to create an Arch Linux ARM rootfs augmented with Nouveau and the OSS graphics stack for NVIDIA's Jetson TK1/TX1 boards
MIT License
60 stars 29 forks source link

nouveau_dri.so: undefined symbol: _glapi_set_nop_handler #8

Closed kratz00 closed 9 years ago

kratz00 commented 9 years ago

weston-launch fails, see log below. Do you have any hints or ideas about the undefined symbol error?

Date: 2000-02-01 UTC
[02:03:01.807] weston 1.7.0
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0
               Build: unknown (not built from git or tarball)
[02:03:01.807] OS: Linux, 4.0.0-171721-g055cb16, #1 SMP PREEMPT Fri May 29 12:25:06 UTC 2015, armv7l
[02:03:01.808] Starting with no config file.
[02:03:01.808] Loading module '/opt/nouveau/lib/weston/drm-backend.so'
[02:03:01.830] initializing drm backend
[02:03:01.832] udev path = /sys/devices/soc0/50000000.host1x/drm/drm/card0
[02:03:01.833] udev path = /sys/devices/soc0/50000000.host1x/drm/drm/card0/card0-HDMI-A-1
[02:03:01.834] udev path = /sys/devices/soc0/57000000.gpu/drm/card1
[02:03:01.836] using /dev/dri/card0
[02:03:01.836] Loading module '/opt/nouveau/lib/weston/gl-renderer.so'
gbm: failed to open any driver (search paths /opt/nouveau/lib/dri)
gbm: Last dlopen error: /opt/nouveau/lib/dri/nouveau_dri.so: undefined symbol: _glapi_set_nop_handler
failed to load driver: nouveau
gbm: failed to open any driver (search paths /opt/nouveau/lib/dri)
gbm: Last dlopen error: /opt/nouveau/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory
failed to load driver: kms_swrast
gbm: failed to open any driver (search paths /opt/nouveau/lib/dri)
gbm: Last dlopen error: /opt/nouveau/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory
failed to load swrast driver
[02:03:01.851] failed to initialize egl
[02:03:01.851] fatal: failed to create compositor
gallit commented 9 years ago

Got the same here on fresh rebuild. Should be a recent regression as i had it working 2 weeks ago.

kratz00 commented 9 years ago

I 'fixed' it. I removed /usr/lib/arm-linux-gnueabihf/libglapi.so.0 and /usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0. weston-launch obviously uses the wrong version of that library, instead of using /opt/nouveau/lib/libglapi.so, it uses /usr/lib/arm-linux-gnueabihf/libglapi.so.0

Gnurou commented 9 years ago

Mmm that's weird. I am at an event this week, but will have a look at this once I'm back to regular work. Thanks for the pointer about the issue!

kratz00 commented 9 years ago

The RPATH of _/opt/nouveau/lib/dri/nouveaudri.so looks like this, interesting are the last two entries. This could be the reason why it picks up the wrong version of libglapi.so

RPATH                /home/vagrant/l4t-nouveau/out/target/L4T/usr/lib/arm-linux-gnueabihf:/home/vagrant/l4t-nouveau/out/target/L4T/opt/nouveau/lib:/usr/lib/arm-linux-gnueabihf:/opt/nouveau/lib
kratz00 commented 9 years ago

I changed the RPATH of _/opt/nouveau/lib/dri/nouveaudri.so which did not result in success. Turns out libgbm.so uses the same RPATH as mentioned above. So i changed the RPATH of /opt/nouveau/lib/libgbm.so and weston-launch succeeded without removing /usr/lib/arm-linux-gnueabihf/libglapi.so.0.

@Gnurou shall I create a pull request for the build-mesa script, which changes the RPATH?

chrpath -r /opt/nouveau/lib /opt/nouveau/lib/libgbm.so
Gnurou commented 9 years ago

I tried doing a fresh build, and weston-launch ran successfully. I am not sure what can trigger this issue.

@kratz00 , feel free to send a pull request, it would be harmless I think.

kratz00 commented 9 years ago

@Gnurou Just out of curiosity, how does the RPATH look for your nouveau_dri.so/libgbm.so files? I will also do a fresh build and then create a pull request if necessary.

Gnurou commented 9 years ago 
$ readelf -d nouveau_dri.so |grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/home/gnurou/Work/tegra-nouveau-rootfs/out/target/L4T/usr/lib/arm-linux-gnueabihf:/home/gnurou/Work/tegra-nouveau-rootfs/out/target/L4T/opt/nouveau/lib:/usr/lib/arm-linux-gnueabihf:/opt/nouveau/lib]

Same as yours it seems - but I am not seeing your error. The only explanation seems to be that the Ubuntu package was defective for a short time.

Still I think we have a problem, the libraries looked up by nouveau_dri.so are not the right ones:

$ ldd nouveau_dri.so 
    ...
    libdrm_nouveau.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm_nouveau.so.2 (0xb679d000)
    libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb678d000)
kratz00 commented 9 years ago

I made some script (https://gist.github.com/kratz00/99533ce856a4d998b44a) to check the RPATHs of all the shared library files in /opt/nouveau/lib.

Some of the libraries contain paths of the build host, which I would say is not nice but harmless and then there is the major problem that /usr/lib/arm-linux-gnueabihf comes before /opt/nouveau/lib.

I have identified three libraries with this problem:

A quick hack would be do add chrpath calls for these libraries in the build-mesa build script.

Gnurou commented 9 years ago

Are we still having this issue? I did a fresh build and things are working without any issue AFAICT.

sarnold commented 9 years ago

I think rpath is at least somewhat "evil" and should really be rpath-link instead. Also, setting the proper path/libs in ld.conf.d would be the right approach to runtime linking. I'm just throwing out a common fix we do on the OS/packaging side (I have not tried the full tegra-rootfs yet, but we're in the process of migrating the right bits to Gentoo now - see gentoo-arm overlay).

Gnurou commented 9 years ago

I really cannot repro this issue. Besides I will be switching the scripts to support Arch Linux by default (Ubuntu/L4T's packages are too old to support latest Xorg/Weston), so I don't think it will apply anymore. Closing this issue for now.