Upon starting x loading r600_dri.so fails
first bad commit : http://cgit.freedesktop.org/mesa/mesa/commit/?id=f70c3853513637fa6ed38e75f73d472a9fa61213
./autogen.sh --prefix=/usr \
I've chosen blocker as severity, as this commit is a candidate for the 9.1 branch
Can you be more specific on how it fails?
X can't initialize the driver and falls back to software rastering.
excerpt from Xorg.0.log :
[ 12609.742] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)
[ 12609.742] (EE) AIGLX: reverting to software rendering
[ 12609.742] (II) AIGLX: Screen 0 is not DRI capable
[ 12609.746] (II) AIGLX: Loaded and initialized swrast
additional info :
OS : Archlinux x86_64
kernel 3.8.3 , https://www.archlinux.org/packages/testing/x86_64/linux/
xf86-video-ati 7.1.0, https://www.archlinux.org/packages/testing/x86_64/xf86-video-ati/
I'll attach the build output and complete Xorg.0.log
Created attachment 76641 [details]
Created attachment 76642 [details]
Created attachment 76652 [details] [review]
Does this patch help?
Tom, could you look at this bug?
yes, the patch in comment #5 solves the problem.
Looking at the 'bad' commit, it seems the changes in
src/gallium/auxiliary/Makefile.am required a change in the
If so, i wonder if other drivers then radeon are affected also.
The patch looks more as a workaround then as a real solution.
(In reply to comment #5)
> Possible patch
This seems less than ideal, as it makes libllvmradeon duplicate lots of stuff from the driver *.so, and it grows from ~500K to ~10M for me.
That appears to be correct,
in a git version build on march 11
libllvmradeon9.2.0.so is just 39 Kib .
Build with the patch it's size increases to 1.8 Mib !
(In reply to comment #8)
> (In reply to comment #5)
> > Possible patch
> This seems less than ideal, as it makes libllvmradeon duplicate lots of
> stuff from the driver *.so, and it grows from ~500K to ~10M for me.
Hmm we definitely need a shared libgallium.
That would reduce the size of all gallium drivers.
Or we could remove/revert the visibility flags from src/gallium/auxiliary/Makefile.am
The fix is correct, despite the size increase.
Reverting the gallium fix would reopen bug #59238
Ubuntu is providing a shared libgallium, the patches are here:
Trying to summarize
I've looked a bit more at bug #59238, and if i understand correctly the problem with building xa tracker was that symbols were exported that are not supposed to be visible outside of the library itself ?
By adding the VISIBILITY_CFLAGS and VISIBILITY_CXXFLAGS changes in the f70c385 commit, the troublesome symbols were removed.
A consequence however was that symbols needed for r600_dri.so to call libllvmradeon9.2.0.so were no longer present.
Including $(top_builddir)/src/gallium/auxiliary/libgallium.la in src/gallium/drivers/radeon/Makefile.am makes sure all needed symbols are present, but has a size increase of libllvmradeon9.2.0 as downside.
To counter the size increase, switching to a shared libgallium is proposed.
Can you please fix this somehow for now? This is preventing radeonsi from working at all.
(In reply to comment #15)
> Can you please fix this somehow for now? This is preventing radeonsi from
> working at all.
I've sent the proposed patch from comment #5 to the list:
(In reply to comment #12)
> Reverting the gallium fix would reopen bug #59238
FWIW, that seems less of an issue to me than this bug or the side effects of the attached patch.
The size increase only happens if radeonsi is built too, and can be countered with the shared libgallium patch.
The original bug described here is fixed with these 2 commits:
36320bfa54b758b34 - radeon/llvm: Link against libgallium.la to fix an undefined symbol
7c3d8301afed46cf9 - radeon/llvm: Do not link against libgallium when building statically.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.