Bugzilla – Bug 5748
drm_cleanup_pci unknown symbol
Last modified: 2006-01-29 13:31:52 UTC
I'm trying for DRI on a hardened LFS.
Kernel-184.108.40.206 with grsecurity, pax, and arc4random patching
compiled using -no-pie -fno-stack-protector-all
gcc-3.4.4 with ssp and hardened specs (-fpic -pie etc)
Xorg-6.9.0 with mesa patch from bug #4197 to remove textrels
Common DRI files from Xorg
Radeon-20060125-linux-i386 for my radeon 7000
I have been using the common files from Xorg because the patch applies cleanly
to mesa, and I have a textrel free libGL.so.1.2 & everything linked against it.
I have hacked the install.sh to provide CC="gcc -no-pie
-fno-stack-protector-all" make in the radeon-* script as the kernel modules
needs this here.
The files from Xorg are linked without -z now. The files from radeon are linked
normally ('-z now' here). I don't know what most of the above implies, as I'm an
end user, not a developer.
I feel sure this is a versions issue, and spotted reference to recent changes
involving drm_compat.h, but grepping for this symbol shows it missing.
modprobe radeon gives me this:
kobject_register failed for drm (-17)
radeon: Unknown symbol drm_cleanup_pci
Can someone suggest a set of versions to get around this? I need to patch with
the patch attached to bug 4197 for this system.
I have tried this now with versions of precompiled as far back as 20051123 (to
try to match in with Xorg's version) and no dice. Same error.
Have you configured your kernel with built-in DRM? If you have then that's the
cause of your problem. You must use a kernel without built-in DRM because it is
incompatible with the DRM in the binary snapshots.
Right! Kernel helped. Thanks to all who spooned me through this.
With CONFIG_DRM not set, I could (Once more) compile a kernel, and once more
compile kernel modules. Glxgears gets shot down instantly by a hardened system
with DRI, but glxinfo tells me I have DRI. I'll file a separate bug for that to
them. I haven't marked this as fixed, because you have problems.
1. Documentation is way behind, especially the website.
2. The build system is nothing short of shambolic, if my experience is
anything to go by. Sorry to nag. I checked out just about everything out of CVS
and could not go from source. I can download a tar.gz of nearly anything else
and build it to suit my system. Not DRI or Mesa. I suffered trying to get
3. There is a need for being able to pass separate CFLAGS to the kernel from
the ones used for Mesa. HLFS have this trick of putting
I used that with success in the linux-core/Makefile.kernel but had to do a bit
of fairly inspirational (for a user) reverse engineering to find where to put it.
4. You need to sort out the DRM kernel issues, or ask them to remove it
from the source. I'm sure they would be glad to save the weight.
Settle on one <expletive-deleted> way of building your code, and perfect that.
To hell with binary releases - That's the m$ way, and it has cost me an
unreasonable amount of effort to get this far.
/FINALLY clears off and leaves you guys alone :-)
Sorry that you had so much trouble building the source. I guess one of the
fundamental problems is the number of components involved that need to match.
There is no such thing as "The DRI Source". However, your experience is not what
the average user should go through. They get their stuff from their
distribution. What you went through is your distribution's job. As to the lack
of documentation, it is unfortunately true that it doesn't always keep up with
the development. However, the website is a wiki. You're welcome to improve the
documentation based on your experience. But keep in mind that the intended
audience is not the average user.
Closing this as NOTABUG.