Compiling 2.6.23.1, do i need 2.6.23.1 headers and modules pkg from slackware package
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Compiling 2.6.23.1 do i need same headers/modules from slackpkg &ATI drv wont compile
I have compiled 2.6.23.1, do i need to download 2.6.23.1 headers and modules pkg from slackware packages?
The first reason why i ask is because is because i am having trouble with installing my ATI drivers. I am grabbing the latest from their website. What i did is after i did a fresh install of slack, i started to configure xorg and setup my vid card. downloaded the ATI drivers from ati and ran the config at runlevel 3. all was well it compiled the driver just great.
configured xorg to use dri and the ATI drivers, started X and i have direct rendering. the only weird thing was when i ran glx_gears or fg_fglrxgears (i think thats what it's called. im not at my pc right now and can't remember) it never displayed a rotating object. i had a really super high FPS though haha. any know why?
At anyrate, because of that i decided to upgrade to the latest kernel. grabbed the source from kernel.org followed the sticky on compiling. i used the config file from 2.6.21.5-huge and then modified for it to select my CPU. after all was done compiling, restarted and booted to the new kernel and tried to rerun the ati drive setup file and now i get a ton of errors when i tries to make the drive. i'll post them if you want once i get home.
Here's what i could think of for possibilities.
Could it be because i used the huge-SMP when i did the fresh install and then did compile for SMP with the new kernel?
Maybe because i didn't remove the driver before i recompiled the kernel?
because ATI linux driver support sucks?
Last night i went to the package repository on slackware.com. saw that there are 2.6.23.1 Headers and a Module package. i installed them. then i found a config file for 2.6.23.1, downloaded that, did a make mrproper and copied it over to my source and recompiled. still can't compile the ATI driver.
The other question is when ever you decide to recompile the latestest and greatest kernel do you need to upgrade your headers and modules? do the /lib/modules/*** dir get updated durring the compile process or is that something that is upkept by pat and thats why it's in slack packages? I just made a vmware server at work using slack and first thing i did was upgrade it to 2.6.23.1 so im just also trying to figure out if i'll need to add the new headers & modules pkg to that box as well.
Last edited by agentc0re; 11-13-2007 at 05:18 PM.
Reason: changing Title
You should leave the original headers package untouched (you should probably reinstall it at this point). After you compile your kernel you should do a "make modules_install" to put the modules in the correct place (you cannot use the slack package of modules if you are using your own kernel). Finally, if you are basing your config on a Slackware config, you should probably use the -generic config rather than the -huge config.
You should leave the original headers package untouched (you should probably reinstall it at this point)
Okay, i'll reinstall the old 2.6.21.5 headers. but why would i not want the updated ones that follow my kernel version?
Quote:
Originally Posted by BCarey
After you compile your kernel you should do a "make modules_install" to put the modules in the correct place (you cannot use the slack package of modules if you are using your own kernel).
I had done the
Code:
make modules_install
when i compiled the kernel. from what i can tell in your reply, when you do this it places them in the /lib/modules/2.6.23.1 dir?
Quote:
Originally Posted by BCarey
Finally, if you are basing your config on a Slackware config, you should probably use the -generic config rather than the -huge config.
I just have to ask why here. I can see obvious reasons, less to compile, less to load in the kernel. any others?
when i compiled the kernel. from what i can tell in your reply, when you do this it places them in the /lib/modules/2.6.23.1 dir?
Yup (assuming you are compiling a 2.6.23.1 kernel). There is a config option to append information to the kernel name, and had you used that it would have copied to, eg. /lib/modules/2.6.23.1-myk
Quote:
I just have to ask why here. I can see obvious reasons, less to compile, less to load in the kernel. any others?
Well, modules still must be compiled, but if you are selective (which the -generic config is not) you can avoid compiling a lot of modules. But the advantage is that you have a much smaller kernel, and for a number of reasons it is nice to have kernel functionality at the module level (you can remove it or add it in, for example, without re-compiling and rebooting, you can try different modules for the same device, etc).
I'm confused.
In CHANGES_AND_HINTS.TXT on the Slackware 12 CD it says:
Quote:
If you are using one of the non-SMP kernels (huge.s or generic.s) and need
to compile third-party modules (such as the proprietary NVidia driver),
have a look in /extra/linux-2.6.21.5-nosmp-sdk/ for information on what
is needed to build them.
It says there to install the "non-smp" kernel headers.
(kernel-headers-2.6.21.5-i386-2.tgz)
Do I first uninstall the header package that's already present?
(kernel-headers-2.6.21.5_smp-i386-2)
Or just install the non-smp headers along with the other?
(doesn't seem right)
Or should I not do anything?
I have'nt had to build any kernel modules yet. But it's I likely will.
(And I'm running the generic non-smp kernel)
I'm confused.
In CHANGES_AND_HINTS.TXT on the Slackware 12 CD it says:
It says there to install the "non-smp" kernel headers.
(kernel-headers-2.6.21.5-i386-2.tgz)
Do I first uninstall the header package that's already present?
(kernel-headers-2.6.21.5_smp-i386-2)
Or just install the non-smp headers along with the other?
(doesn't seem right)
Or should I not do anything?
I have'nt had to build any kernel modules yet. But it's I likely will.
(And I'm running the generic non-smp kernel)
Use upgradepkg(8) or either uninstall the smp headers and then install the non-smp headers.
upgradepkg(8) is the most elegant option, and definitely the recommended option. In this case, it doesn't matter, but there are some packages that uninstalling first would create less than desirable results :-)
If you read the sticky on compiling and the million other guides out there, you would have seen that you DO NOT need to remove any packages at all.
I admit to not STF but i've always gone by the stick for compiling. I don't see any mention of that on the first page. maybe daone or someone with rights could update the post. and from the looks of the post after about the changes and hints.txt that i will need to change my headers to the non-smp headers since i'm not compiling for that. please correct me if im wrong.
maybe thats why im having problems trying to get the ati driver to compile?
Code:
ATI module generator V 2.0
==========================
initializing...
build_date =Tue Nov 13 06:45:28 MST 2007
uname -a =Linux monkeysex 2.6.23.1 #1 Mon Nov 12 23:03:37 MST 2007 i686 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux
uname -s =Linux
uname -m =i686
uname -r =2.6.23.1
uname -v =#1 Mon Nov 12 23:03:37 MST 2007
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),17(audio),18(video),19(cdrom),83(plugdev)
.
drwxr-xr-x 234 root root 40960 2007-11-12 22:06 /usr/include
.
total 92
drwxr-xr-x 2 root root 4096 2007-11-13 06:21 ati
-rw-r--r-- 1 root root 74223 2007-11-12 22:27 config-huge-2.6.23.1
lrwxrwxrwx 1 root root 14 2007-11-11 22:32 linux -> linux-2.6.23.1
drwxr-xr-x 19 root root 4096 2007-06-19 13:48 linux-2.6.21.5
drwxrwxr-x 20 root root 4096 2007-11-13 06:24 linux-2.6.23.1
.
file /lib/modules/2.6.23.1/build/include/linux/agp_backend.h says: AGP=1
file /proc/kallsyms says: SMP=1
file /lib/modules/2.6.23.1/build/include/linux/autoconf.h says: SMP=
file /lib/modules/2.6.23.1/build/include/linux/autoconf.h says: MODVERSIONS=
.
CC=gcc
cc_version=
found major but not minor version match for gcc and the ip-library
ls -l ./libfglrx_ip.a
lrwxrwxrwx 1 root root 18 2007-11-13 06:45 ./libfglrx_ip.a -> libfglrx_ip.a.GCC4
.
cleaning...
patching 'highmem.h'...
assuming new VMA API since we do have kernel 2.6.x...
def_vma_api_version=-DFGL_LINUX253P1_VMA_API
Assuming default VMAP API
Assuming default munmap API
doing Makefile based build for kernel 2.6.x and higher
make -C /lib/modules/2.6.23.1/build SUBDIRS=/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory `/usr/src/linux-2.6.23.1'
CC [M] /lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:365: warning: initialization from incompatible pointer type
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:366: warning: initialization from incompatible pointer type
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'fglrx_pci_suspend':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:799: warning: passing argument 1 of 'firegl_pci_save_state' from incompatible pointer type
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'fglrx_pci_resume':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:841: warning: passing argument 1 of 'firegl_pci_restore_state' from incompatible pointer type
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_check_pci':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:1990: warning: 'pci_find_slot' is deprecated (declared at include/linux/pci.h:481)
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_pci_find_device':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2019: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:480)
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_vm_test_and_clear_dirty':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2544: error: implicit declaration of function 'ptep_test_and_clear_dirty'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_pci_find_slot':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2852: warning: 'pci_find_slot' is deprecated (declared at include/linux/pci.h:481)
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_request_irq':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2962: warning: 'deprecated_irq_flag' is deprecated (declared at include/linux/interrupt.h:64)
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2962: warning: passing argument 2 of 'request_irq' from incompatible pointer type
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function '__ke_pte_phys_addr_str':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:3536: error: implicit declaration of function 'pte_read'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:3538: error: implicit declaration of function 'pte_exec'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: At top level:
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5439: error: expected specifier-qualifier-list before 'kmem_cache_t'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'KAS_SlabCache_Initialize':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5478: error: 'kasSlabCache_t' has no member named 'routine_type'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5479: error: 'kasSlabCache_t' has no member named 'lock'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5480: error: 'kasSlabCache_t' has no member named 'name'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5484: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5485: error: 'kasSlabCache_t' has no member named 'name'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5485: error: too many arguments to function 'kmem_cache_create'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'KAS_SlabCache_Destroy':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5508: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5518: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5520: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'KAS_SlabCache_AllocEntry':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5555: error: 'kasSlabCache_t' has no member named 'routine_type'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5556: error: 'kasSlabCache_t' has no member named 'lock'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5580: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5583: error: 'kasSlabCache_t' has no member named 'lock'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5591: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'KAS_SlabCache_FreeEntry':
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5619: error: 'kasSlabCache_t' has no member named 'routine_type'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5620: error: 'kasSlabCache_t' has no member named 'lock'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5632: error: 'kasSlabCache_t' has no member named 'cache'
/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5635: error: 'kasSlabCache_t' has no member named 'lock'
make[2]: *** [/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1
make[1]: *** [_module_/lib/modules/fglrx/build_mod/2.6.x] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.23.1'
make: *** [kmod_build] Error 2
build failed with return value 2
Forgive me for butting in here but I'm a newbie trying to learn this along with agentc0re and I'm now thoroughly confused by the discussion.
I was told by a good friend NEVER to touch my kernel headers, and that the header package installed with Slack12 would compile any and all software I would need for my machine, and that the 2.6.21.5 headers will work fine with any kernel from the 2.6 series.
Forgive me for butting in here but I'm a newbie trying to learn this along with agentc0re and I'm now thoroughly confused by the discussion.
I was told by a good friend NEVER to touch my kernel headers, and that the header package installed with Slack12 would compile any and all software I would need for my machine, and that the 2.6.21.5 headers will work fine with any kernel from the 2.6 series.
Please advise if I was instructed wrong.
Dig
You are basically correct. The "non-smp headers" should only be used if you have problems compiling _kernel modules_. (I run my own kernel but have had no trouble compiling modules with the smp headers.)
The links supplied by rworkman explain all this. The headers need to match the headers used when glibc was compiled, they don't need to match the currently used kernel.
You are basically correct. The "non-smp headers" should only be used if you have problems compiling _kernel modules_.
Okay thanks, Brian!
I've compiled a bunch of software now for my new Slack12 machine, and have also compiled a few custom 2.6.23.1 kernels... of which some have worked better than others. LOL. But to date I've never had a problem compiling anything with the stock 2.6.21.5 headers so I just wanted to make sure.
It looks like you are still using the 2.6.23.1 headers.
Brian
From what i can tell those DIR's are reflections of my /usr/src/XXX
i have the new source in there and followed
Quote:
Now, make install still works great as long as the above is done. So...once the kernel source is downloaded and extracted to /usr/src, you can then create a new link.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
haha. any know why? 
