Thank you to all those that responded. Ultimately, I searched the Fedora database. Thank you all for your patience, I know people tend to repeat questions an annoyingly high amount. That database is a very handy tool. I wish more people would know about it, but thanks for the heads up.
Best Regards, Scott
From: Peter Backlund peter.backlund@home.se Reply-To: fedora-list@redhat.com To: fedora-list@redhat.com Subject: Re: NVIDIA driver compile Date: Fri, 21 Nov 2003 17:31:55 +0100
As pointed out in the #fedora FAQ on fedora.artoo.net, there are rpms for the nvidia driver, along with installation instructions.
Go to
http://www2.educ.umu.se/~peter/nvidia/
Read the README, then download and install. Automatic configuration.
/Peter
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
_________________________________________________________________ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now! http://join.msn.com/?PAGE=features/es
As pointed out in the #fedora FAQ on fedora.artoo.net, there are rpms for the nvidia driver, along with installation instructions.
What is so hard about installing with the source from nVidia's site? I just installed Fedora Core 1 and did this on the weekend and it worked PERFECTLY!
1. Go to http://www.nvidia.com/object/linux_display_ia32_1.0-4496.html 2. Download NVIDIA-Linux-x86-1.0-4496-pkg2.run 3. Boot system in text mode (edit /etc/inittab and set run level to 3) 3. type "export CC=gcc32" 4. type "sh NVIDIA-Linux-x86-1.0-4496-pkg2.run" 5. Edit the /etc/X11/XF86Config file as described in the readme file 6. Boot the system in Gui mode (edit /etc/inittab and set run level to 5)
No thanks.
1) I see no reason to do additional work when rpmbuild -ba will do the job
2) Everyone who has done some _serious_ software building will tell you that compiling from a tar ball is highly unreliable. configure will build a different executable depending on what it finds on the machine and the flags you pass to the configure script. One of the nice things about building from an SRPM is that the falgs to configure are well defined and that the Build-time dependencies ensure you won't build a software so crippled to be nearly unusable (eg a Gimp who doesn't handle Jpegs)
3) Last but not least when I build from an SRPM I get an RPM. I don't want to return to the bad old times where I feared something I installed would trash my sendmail config, where uninstalling something could break that half of the programs who depended upon it, where once something was installed uninstalling became nearly impossible, where I didn't knew what was on my box and what it did. If I enjoyed these things I would be running Slackware. I don't enjoy them.
BTW, building the Nvidia RPM is trivial, you have just to turn off the build of a debug RPM
On Mon, 2003-11-24 at 00:27, Peter Kiem wrote:
As pointed out in the #fedora FAQ on fedora.artoo.net, there are rpms for the nvidia driver, along with installation instructions.
What is so hard about installing with the source from nVidia's site? I just installed Fedora Core 1 and did this on the weekend and it worked PERFECTLY!
- Go to http://www.nvidia.com/object/linux_display_ia32_1.0-4496.html
- Download NVIDIA-Linux-x86-1.0-4496-pkg2.run
- Boot system in text mode (edit /etc/inittab and set run level to 3)
- type "export CC=gcc32"
- type "sh NVIDIA-Linux-x86-1.0-4496-pkg2.run"
- Edit the /etc/X11/XF86Config file as described in the readme file
- Boot the system in Gui mode (edit /etc/inittab and set run level to 5)
- Everyone who has done some _serious_ software building will tell you
that compiling from a tar ball is highly unreliable. configure will
Rubbish. SRPMS **ARE** basically packaged tarballs inside!
I've built from SRPMS, tarballs and even tarballs to create an RPM and no one way is more reliable than the others. I've had problems with all methods but mostly no problems either way.
- Last but not least when I build from an SRPM I get an RPM. I don't
Yes I normally prefer RPMs as well but I prefer to get my video drivers from the source instead of a 3rd party who I don't know or trust.
BTW, building the Nvidia RPM is trivial, you have just to turn off the build of a debug RPM
BTW, building the nVidia drivers following the instructions from nVidia is trivial too!
The only gotcha was the "export CC=gcc32" but other than that it was follow the bouncing ball material.
I was pointing out to the original poster who couldn't get the tarball from nVidia to compile the steps required rather than having to go elsewhere.
On Tue, 2003-11-25 at 00:29, Peter Kiem wrote:
- Everyone who has done some _serious_ software building will tell you
that compiling from a tar ball is highly unreliable. configure will
Rubbish. SRPMS **ARE** basically packaged tarballs inside!
SRPMS are a lot more than tarballs since they define build time dependencies (ie they refuse to build if this or that isn't installed), configure flags (eg --with-acl, --with-openldap in the case of samba) install-time configure scripts
I've built from SRPMS, tarballs and even tarballs to create an RPM and no one way is more reliable than the others. I've had problems with all methods but mostly no problems either way.
I have built some hundreds and unlike you pais attention to the messages paid by configure
Lets give an example of things going wrong:
You build the library foo. There are optional features who depend of BAR but while they are important they will not cause configure to abort the compilation.
The firt time you build FOO the configure script detects the library bar and builds a foo who is bar aware. Now you build some apps who use foo but whose configure will detect that your foo is bar aware and your applications will be built bar aware
One day you uninstall the bar-devel package. No problem. The day after you learn of a security hole in foo so you patch and rebuild it. But this time configure doesn't detect bar so when you install it all those apps who relied on will BREAK
In the case of an SRPM the packager can give a list of build time dependencies, admittedly they are generally incomplete since they have to be built by hand but packager can still ensure nothing important is left out or that it will fit the environment (eg a distro he knows it ships with BAR)
- Last but not least when I build from an SRPM I get an RPM. I don't
Yes I normally prefer RPMs as well but I prefer to get my video drivers from the source instead of a 3rd party who I don't know or trust.
BTW, building the Nvidia RPM is trivial, you have just to turn off the build of a debug RPM
BTW, building the nVidia drivers following the instructions from nVidia is trivial too!
The only gotcha was the "export CC=gcc32" but other than that it was follow the bouncing ball material.
I was pointing out to the original poster who couldn't get the tarball from nVidia to compile the steps required rather than having to go elsewhere.
Nvidia provides SRPMS so in that case it is pointless to use the tarball. If it doesn't build then taking a look at the third party srpm and using the info for building the NVIDIA provided SRPM is the best option
SRPMS are a lot more than tarballs since they define build time dependencies (ie they refuse to build if this or that isn't installed), configure flags (eg --with-acl, --with-openldap in the case of samba) install-time configure scripts
My point was that SRPMS are bascially a wrapper around tarball installs.
There is nothing magically inherent in SRPMS rather than tarballs other than the SRPM author has added configuration information for building the (usually) tarred source inside the SRPM by providing the SPEC files. When it comes down to it the SRPM will also be using tar and configure anyway.
Heck, even some .tgz downloads provide a SPEC file so you can build SRPMS from them yourself.
And yes, I usually prefer to install from SRPMS myself and to use tarballs as a last resort.
Nvidia provides SRPMS so in that case it is pointless to use the tarball. If it doesn't build then taking a look at the third party srpm and using the info for building the NVIDIA provided SRPM is the best option
Out of interest where are the SRPMS? I can see them listed for the nForce drivers 1.0-0261 but not for the Linux IA-32 drivers which I was using.
Anyway, I don't want to get into a pissing match with you about SRPMS vs tarballs. Someone asked why they couldn't get the nVidia drivers to compile and I told them.
You want to use RPMS religiously throughout your system? Fine, go do it!
I mostly do as well but I am FLEXIBLE and use whatever suits my needs at the time on my own systems.
At the time I couldn't find SRPMS suitable for Fedora on the nVidia site but using their provided package, with their provided README, I was able to compile and load their drivers PERFECTLY on Fedora.
On Tue, 2003-11-25 at 01:25, Peter Kiem wrote:
SRPMS are a lot more than tarballs since they define build time dependencies (ie they refuse to build if this or that isn't installed), configure flags (eg --with-acl, --with-openldap in the case of samba) install-time configure scripts
My point was that SRPMS are bascially a wrapper around tarball installs.
Can I pitch in a couple of Lincolns?
I first touched a Unix machine in 1989. My resume, for which I waited at the local printer came out in Albuquerque. This taught me two things I didn't notice until much later:
1. Unix is an interesting world with LOTS of cool tools.
2. Things don't always work the way they seem, so you have to try to make things easy for the user (who may, or may NOT remember where the default printer is.)
I've spent tens of thousands of hours sitting behind a black-n-white 80x24 screen untarring files and wishing I knew all the details.
PLEASE DON'T MAKE ME GO BACK THERE.
SRPMS are nice; like someone leaving a reel-type lawn mower for a brand-new power mower and mulcher that doesn't have to be emptied, I really don't want to go back to the way it was before.
Yeah, tarballs are more flexible; if you know every library it might ever need, you can build a tarball for a MIPS or DEC or whatever...but lets think about this: since the RPM package is built for almost everything short of a Timex $2 watch, how about we build everything in SRPMs, and make use of their inherent ability to build for multiple platforms?
I remember people clinging to non-windows machines...they were pathetic, and I was one of'em.
But trust me: I don't have time to remember the dependency tree for all 3,000-or-so RPM packages, and I shouldn't have to.
SRPMs/RPMs are an evolution. Just like using, say, MySQL is easier than maintaining flat-files, re-writing locking routines every time someone needs another phone-book app, it's a tool. And we're darned lucky to have it: it does everything we need it to, and if it doesn't, we'll add to it.
They allow the few among us who program to give a hand to the rest of us a hand-up to get things going. And a program that can't be installed is just a datafile, right?
It's not about programmer-macho, it's not about the guy that memorizes all the xlib calls by heart...it's about saving time and shortening the time it takes to make that huge, killer-app.
If you really need the power of a tarball, feel free to install it and copy it anywhere. But the rest of us will just rpmbuild and hope for the best.
Enjoy! Rejoice in the power of RPMS!
Hi Brian,
I've spent tens of thousands of hours sitting behind a black-n-white80x24 screen untarring files and wishing I knew all the details.
PLEASE DON'T MAKE ME GO BACK THERE. SRPMS are nice; like someone leaving a reel-type lawn mower for a
Yes I don't disagree with you there Brian. I myself much prefer RPMS and only resort to tarballs when necessary. I think RPMS are great for installing and keeping systems running smoothly.
I don't need however, some pompous person telling me that for "_serious_ software building" that SRPMS are a magic bullet and tars are "highly unreliable". That is complete Bulls**t!
I'm a developer and system administrator by profession myself so I understand computer systems and software quite well thank you very much Jean.
Anyway the original post was how to compile under a previous gcc release which I answered instead of telling the poster to go load something else instead.
Anyway enough noise now, let's all go back to being happy little Fedora users :)
Enjoy! Rejoice in the power of RPMS!
Where available :)
On 25 Nov 2003 07:59:21 +0100, you wrote:
Nvidia provides SRPMS so in that case it is pointless to use the tarball. If it doesn't build then taking a look at the third party srpm and using the info for building the NVIDIA provided SRPM is the best option
NVIDIA no longer provides RPMS or SRPMS.
NVIDIA has used their custom install program for all drivers releases this year (3 releases so far).
While you can find RPMS/SRPMS these are provided by Suse not NVIDIA.
On Mon, 24 Nov 2003, Peter Kiem wrote:
What is so hard about installing with the source from nVidia's site? I just installed Fedora Core 1 and did this on the weekend and it worked PERFECTLY! 1..2..3..4..5..6
OK so far... May I add #7.
7. /usr/bin/X11/x11perf -all > /tmp/x11perf-out-nvidia
Things 1-6 work fine for me. Number 7 dumps core both for the nvidia driver and the nv driver. The nvidia driver crashed the Xserver. An old SiS300 based PCI card did run this test to competion.
When running the nvidia driver the last line in the log file was:
2800 reps @ 1.8933 msec ( 528.0/sec): ShmPutImage XY 100x100 square
"lspci" tells me ....nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)
I am using my 'safe' XF86Config from my RH9 box with an older nVidia card that does fine with x11perf: ....nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) I will look to see if I missed anything in the sample XF86Config files. I noted that /usr/bin/redhat-config-xfree86 had trouble on Fedora.
Anyhow can other nVidia card holders with time please run: /usr/bin/X11/x11perf -all and validate that I am alone or in a crowd on this.
Tom Mitchell wrote:
May I add #7.
- /usr/bin/X11/x11perf -all > /tmp/x11perf-out-nvidia
Things 1-6 work fine for me. Number 7 dumps core both for the nvidia driver and the nv driver. The nvidia driver crashed the Xserver. An old SiS300 based PCI card did run this test to competion.
When running the nvidia driver the last line in the log file was:
2800 reps @ 1.8933 msec ( 528.0/sec): ShmPutImage XY 100x100 square
"lspci" tells me ....nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)
I am using my 'safe' XF86Config from my RH9 box with an older nVidia card that does fine with x11perf: ....nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) I will look to see if I missed anything in the sample XF86Config files. I noted that /usr/bin/redhat-config-xfree86 had trouble on Fedora.
Anyhow can other nVidia card holders with time please run: /usr/bin/X11/x11perf -all and validate that I am alone or in a crowd on this.
you need to type export CC=gcc322 before you compile the nvidia source. I have a 440 card just like yours and both nvidia and nv drivers work fine although I have a small problem with DRI. /usr/bin/X11/x11perf -all does not core dump but also does display some funny lines in the right corner.
On Mon, 2003-12-01 at 09:46, Tom Mitchell wrote:
Anyhow can other nVidia card holders with time please run: /usr/bin/X11/x11perf -all and validate that I am alone or in a crowd on this.
Works for me no problems (once I disabled xscreensaver)...took forever though.
On Mon, 1 Dec 2003, fs wrote:
Tom Mitchell wrote:
May I add #7.
- /usr/bin/X11/x11perf -all > /tmp/x11perf-out-nvidia
Things 1-6 work fine for me. Number 7 dumps core both for the
....
you need to type export CC=gcc322 before you compile the nvidia source.
This I had done. The compile+install of the nvidia package seems fine. Simple X-window stuff is stable and fine.
I have a 440 card just like yours and both nvidia and nv drivers work fine although I have a small problem with DRI. /usr/bin/X11/x11perf -all does not core dump but also does display some funny lines in the right corner.
I will look into DRI and other x+gl-features and see what changes.
So far the segv happens at different places in the test sequence so I suspect a software collision or trouble communicating with the x-server.
After a second/third install of the nvidia driver the x-server is stable and only x11perf errors out.
I will keep tinkering.
On Mon, 2003-12-01 at 17:33, Tom Mitchell wrote:
I have a 440 card just like yours and both nvidia and nv drivers work fine although I have a small problem with DRI. /usr/bin/X11/x11perf -all does not core dump but also does display some funny lines in the right corner.
I will look into DRI and other x+gl-features and see what changes.
So far the segv happens at different places in the test sequence so I suspect a software collision or trouble communicating with the x-server.
After a second/third install of the nvidia driver the x-server is stable and only x11perf errors out.
I will keep tinkering.
Maybe this clue will help. (Granted, it's only a clue-let.)
The distortion he's seeing sounds exactly like what I'm seeing now with a fresh install under Fedora...and what I had when trying to squeeze a few more FPS outta the 3d acceleration.
The tweak was a minor fix; nothing so bold as to overclock it, but something that was controlled under an environment variable listed in the Release Notes from Nvidia.
I'm sorry I don't have more information; it was a little tweak, and the FPS it resulted in was less than worth the trouble...so I didn't bother to write it down. I think it was the thing that syncs the frames...
Sorry I don't have more to go on, but it sounds like it's something that defaulted off, and nowdays it defaults to on. Good luck with it.
If you want some help with it, I can help ya shake the trees.
---------- Original Message ----------- From: Tom Mitchell mitch48@sbcglobal.net To: fedora-list@redhat.com Sent: Mon, 1 Dec 2003 15:33:59 -0800 (PST) Subject: Re: NVIDIA driver compile
On Mon, 1 Dec 2003, fs wrote:
Tom Mitchell wrote:
May I add #7.
- /usr/bin/X11/x11perf -all > /tmp/x11perf-out-nvidia
Things 1-6 work fine for me. Number 7 dumps core both for the
....
you need to type export CC=gcc322 before you compile the nvidia source.
This I had done. The compile+install of the nvidia package seems fine. Simple X-window stuff is stable and fine.
I have a 440 card just like yours and both nvidia and nv drivers work fine although I have a small problem with DRI. /usr/bin/X11/x11perf -all does not core dump but also does display some funny lines in the right corner.
I will look into DRI and other x+gl-features and see what changes.
So far the segv happens at different places in the test sequence so I suspect a software collision or trouble communicating with the x-server.
After a second/third install of the nvidia driver the x-server is stable and only x11perf errors out.
I will keep tinkering.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
------- End of Original Message -------
Have you removed the DRI references in your XF86Config file as outlined in the Nvidia Driver README. As this driver does not use DRI.
Wolf
On Tue, 2 Dec 2003, Wolfgang Gill wrote:
---------- Original Message ----------- From: Tom Mitchell mitch48@sbcglobal.net
Tom Mitchell wrote:
May I add #7.
- /usr/bin/X11/x11perf -all > /tmp/x11perf-out-nvidia
Yes the DRI references were removed as per the release notes.
Right now I am double checking BIOS settings in case some optimum .vs. safe setting is involved.
Have you removed the DRI references in your XF86Config file as outlined in the Nvidia Driver README. As this driver does not use DRI.
Wolf
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-
Brian Fahrlander -
Gerald Henriksen -
Info -
Jean Francois Martinez -
nosp -
Peter Kiem -
Scott Fones -
Tom Mitchell -
Wolfgang