Upgrading XFree86 on slink for i810 chipset
I need your advice. I have an Intel i810 chipset and the driver requires XFree86 version 3.3.6, but slink has 3.3.2. The driver also requires a kernel module which is for 2.2 kernels, while slink has 2.0 kernels. Additionally, the Intel support site offers the driver, and they say the i810 driver also needs glibc2.1, presumably because they distribute it as a binary file compiled for glibc2.1. But slink only has glibc2.0. First question: Do I really need glibc2.1, or can I build XFree86 and the driver with glibc2.0? I notice two different versions of the 3.3.6 binaries for depending on which version of glibc. Unfortunately I didn't see the i810 driver in the binary directories, but I did find it in the Xfree86 sources. For the best stability, would it be better to try to keep glibc 2.0 and build the driver on slink, or would the best solution to be to upgrade to potato, which has kernel 2.2 and glibc2.1, but is not the stable version and just install the binary from Intel? No matter what I will have to upgrade the kernel to 2.2 to run the agpgart kernel module. Thanks in advance. Br. Chuck Zmudzinski
Re: Upgrading XFree86 on slink for i810 chipset
On Wed, 26 Jul 2000, Br. Chuck Zmudzinski wrote: brchuc First question: Do I really need glibc2.1, or can I build XFree86 and the brchuc driver with glibc2.0? I notice two different versions of the 3.3.6 binaries brchuc for depending on which version of glibc. Unfortunately I didn't see the i810 brchuc driver in the binary directories, but I did find it in the Xfree86 sources. you can build with 2.0 no prob, u must ge tthe right driver though there are several versions. You can find it in the XF86 3.3.6 source distribution. or you can download it from me: http://www.firetrail.com/~aphro/agpgart-source.tar.gz make sure the version-test.sh is executable when compiling it or it will puke. ive used this on about 10 different boxes. brchuc For the best stability, would it be better to try to keep glibc 2.0 and brchuc build the driver on slink, or would the best solution to be to upgrade to brchuc potato, which has kernel 2.2 and glibc2.1, but is not the stable version and brchuc just install the binary from Intel? No matter what I will have to upgrade brchuc the kernel to 2.2 to run the agpgart kernel module. as far as stability is concerned both 2.1 and 2.2 are about the same, the only prob i had in 2.1 is that the keyboard would not work with a display manager (XDM, KDM etc) using the i810, but works fine in 2.2 (dont think its related but never know..) nate ::: http://www.aphroland.org/ http://www.linuxpowered.net/ [EMAIL PROTECTED] 8:01pm up 9 days, 3:29, 1 user, load average: 0.00, 0.00, 0.00
Re: Upgrading XFree86 on slink for i810 chipset
go ahead an upgrade to potato. i've been using it for about 6mo and it's been very stable. On Wed, Jul 26, 2000 at 09:43:28PM -0500, Br. Chuck Zmudzinski wrote: I need your advice. I have an Intel i810 chipset and the driver requires XFree86 version 3.3.6, but slink has 3.3.2. The driver also requires a kernel module which is for 2.2 kernels, while slink has 2.0 kernels. Additionally, the Intel support site offers the driver, and they say the i810 driver also needs glibc2.1, presumably because they distribute it as a binary file compiled for glibc2.1. But slink only has glibc2.0. First question: Do I really need glibc2.1, or can I build XFree86 and the driver with glibc2.0? I notice two different versions of the 3.3.6 binaries for depending on which version of glibc. Unfortunately I didn't see the i810 driver in the binary directories, but I did find it in the Xfree86 sources. For the best stability, would it be better to try to keep glibc 2.0 and build the driver on slink, or would the best solution to be to upgrade to potato, which has kernel 2.2 and glibc2.1, but is not the stable version and just install the binary from Intel? No matter what I will have to upgrade the kernel to 2.2 to run the agpgart kernel module. Thanks in advance. Br. Chuck Zmudzinski -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- As a general rule, if you have trouble with the binary system, then probably it is because you do not really understand the decimal system ... R.W. Hamming
