libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: _ZN4llvm19createGlobalDCEPassEv)
with mesa head at:
Not sure if it's a mesa or llvm regression.
Is that with or without --with-llvm-shared-libs for the Mesa build?
without. Is that required now?
My configure options are:
./autogen.sh --prefix=/usr --libdir=/usr/lib64 --with-dri-drivers=radeon,r200 --with-gallium-drivers=r300,r600,radeonsi,swrast --enable-gles1 --enable-gles2 --enable-xorg --enable-vdpau --enable-shared-glapi --enable-gbm --enable-gallium-llvm --with-egl-platforms=drm --enable-glx-tls --enable-debug
Also, I'm using llvm c5c65f9ad0e1e897f6d828248bdf25a6714cdd09 from Tom's tree.
(In reply to comment #2)
> without. Is that required now?
No, but I do wonder if we shouldn't drop support for linking LLVM statically.
The problem is that llvm_wrapper.cpp is being built without --enable-opencl or --enable-r600-llvm-compiler, so the necessary libraries haven't been added to LLVM_LIBS. The fix is to disable building of llvm_wrapper.cpp in this case. I will write a patch.
It was false to remove libr600_la_LDFLAGS in this patch:
And please change all Makefile.am to generate LLVM related LIBADDs this way to avoid stupid dependencies if LLVM was compiled with the better cmake build system which creates shared instead of static libs / one big shared lib and can save memory this way.
This should be fixed by this patch:
(In reply to comment #5)
> It was false to remove libr600_la_LDFLAGS in this patch:
> And please change all Makefile.am to generate LLVM related LIBADDs this way
> to avoid stupid dependencies if LLVM was compiled with the better cmake
> build system which creates shared instead of static libs / one big shared
> lib and can save memory this way.
Generating different shared libraries depending on the build system used is a bug in LLVM. However, until it is fixed we need to support both build systems even if one is better.
Adding llvm libraries in makefiles using llvm-config will not work when we are linking against shared libraries generated by an autotools build of LLVM, because then we will be linking against shared and static libraries at the same time.