| Summary: | loader.c:71:19: fatal error: dlfcn.h: No such file or directory | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | medium | CC: | alexandre.f.demers, brianp, emil.l.velikov, eric, keithp, mike |
| Version: | git | Keywords: | regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | loader: include dlfcn.h when building with HAVE_LIBUDEV | ||
Why is DRI code being built for a windows target? Sounds like scons's windows build is wrong. > Why is DRI code being built for a windows target? Sounds like scons's windows build is wrong. Yes, it appears that there is no point to build loader for windows. However egl-static was supposed to buil on Windows and it is now hardcoded to depend on loader: Linking build/windows-x86-debug/gallium/targets/egl-static/libEGL.dll ... build/windows-x86-debug/gallium/targets/egl-static/egl.o: In function `create_drm_screen': /home/jfonseca/projects/opengl/mesa/src/gallium/targets/egl-static/egl.c:64: undefined reference to `_loader_get_driver_for_fd' build/windows-x86-debug/gallium/targets/egl-static/egl.o: In function `loader_init': /home/jfonseca/projects/opengl/mesa/src/gallium/targets/egl-static/egl.c:99: undefined reference to `_loader_set_logger' collect2: ld returned 1 exit status scons: *** [build/windows-x86-debug/gallium/targets/egl-static/libEGL.dll] Error 1 Not sure what to do here. I suspect I'll have to revert http://cgit.freedesktop.org/mesa/mesa/commit/?id=a9800242244098fddcd2b963d8f5ccda5dea8290 and a few more until the cross-platform portability of loader is addressed. Emil, if you could into this it would be appreciated. To repro all you need is cross-mingw compilers installed, and do scons platform=windows toolchain=crossmingw Created attachment 92914 [details] [review] loader: include dlfcn.h when building with HAVE_LIBUDEV (In reply to comment #1) > Why is DRI code being built for a windows target? Sounds like scons's > windows build is wrong. I don't think DRI is betting build here, I'm assuming egl-static is causing the problem. (In reply to comment #2) > I suspect I'll have to revert > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=a9800242244098fddcd2b963d8f5ccda5dea8290 and a few more until the > cross-platform portability of loader is addressed. > > Emil, if you could into this it would be appreciated. To repro all you need > is cross-mingw compilers installed, and do > > scons platform=windows toolchain=crossmingw I do not have the cross compilation chain although the fix seems trivial. Wrap the headers in HAVE_LIBUDEV, similar to the code that depends on them. (In reply to comment #3) > I do not have the cross compilation chain although the fix seems trivial. > Wrap the headers in HAVE_LIBUDEV, similar to the code that depends on them. Thanks. Pushed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
mesa: 3f3aafbfeeb3939cb5cf710954ccefb8bbe9cff9 $ scons platform=windows toolchain=crossmingw machine=x86_64 [...] Compiling src/loader/loader.c ... src/loader/loader.c:71:19: fatal error: dlfcn.h: No such file or directory #include <dlfcn.h> ^ 4556c734700da2dd95d4f148d6929a537882bade is the first bad commit commit 4556c734700da2dd95d4f148d6929a537882bade Author: Eric Anholt <eric@anholt.net> Date: Thu Jan 23 13:12:26 2014 -0800 loader: Use dlsym to get our udev symbols instead of explicit linking. Steam links against libudev.so.0, while we're linking against libudev.so.1. The result is that the symbol names (which are the same in the two libraries) end up conflicting, and some of the usage of .so.1 calls the .so.0 bits, which have different internal structures, and segfaults happen. By using a dlopen() with RTLD_LOCAL, we can explicitly look for the symbols we want, while they get the symbols they want. Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> :100644 100644 33ac92259485ffdbd572f1d1d515f4b0912d2eda d266d96b67478c8b86498d2851a925b0ecd774c9 M configure.ac :040000 040000 b182b18567800d07af87ee1fc6ea0cf3240b2843 984c15307040226fd44d1cd84fa0e09e5ac26a90 M src bisect run success