how to deal with nvidia driver/libs
I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. so far I have solved the following conflicts with dpkg-divert. /usr/X11R6/lib/modules/extensions libGLcore.a.distrib # local diversion libglx.a.distrib# local diversion libglx.so - libglx.so.1.0.5# from nvidia libglx.so.1.0.5 # from nvidia /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia /usr/lib libGLcore.so - libGLcore.so.1 # from nvidia libGLcore.so.1 - libGLcore.so.1.0.5# from nvidia libGLcore.so.1.0.5 # from nvidia libGL.so - libGL.so.1 # here comes the problematic one libGL.so.1 - libGL.so.1.2 libGL.so.1.0.5 # from nvidia libGL.so.1.2# xlibmesa3 xlibmesa3 provides libGL.so.1.2 and something insist on libGL.so.1 pointing to it. I tried to divert the link, so that my link (libGL.so.1 - libGL.so.1.0.5) is not delete by xlibmesa3. This works fine during package install, but as soon as ldconfig is called, my link is replace by libGL.so.1 - libGL.so.1.2. How can I stop this? Is there a better approach of integrating the vendor supplied drivers? regards ff -- Florian Friesdorf [EMAIL PROTECTED] OpenPGP key available on public key servers -- Save the future of Open Source -- - Online-Petition against Software Patents - -- http://petition.eurolinux.org --- PGP signature
Re: how to deal with nvidia driver/libs
On Thu, Oct 12, 2000 at 04:10:10AM +0200, Florian Friesdorf wrote: I diverted nv, because of xf86cfg failing to start, because of to conflicting drivers. ahh, I went through the config with the stock drivers before even extracting the nvidia stuff just to make sure the shipping defaults would at least get me a usable display. afterwards it was just a couple of tweaks in the config file and nvidia's driver was humming along happily.. Ok, then I will have a look at the packaging manual. as a final note, the recipe I used to cook my stuff up was to start with: for the -GLX package I started with debhelper (hadn't used it for any personal packages yet and was curious about what it was like from an initial packaging point of view) and used the ROOT variable in nvidia's Makefile to install the necessary files in the debian/tmp dir .. added in the docs and removed the _drv.o file from the dh_shlibdeps call .. after that was just the standard stuff of filling out the control file and changelogs and such. the second step was to create a framework for the module, my solution there was to start with the source tree that device3dfx installs and use that structure as the start of a sourcetree for the nvidia module component. this way a 'make-kpkg kernel-image modules-image' builds everything necessary and I don't hafta remember to go back out and build the module seperately before rebooting.. hopefully the notes above will help you and anybody else interested in building custom .deb's for these drivers make your own packages.. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how to deal with nvidia driver/libs
I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. so far I have solved the following conflicts with dpkg-divert. /usr/X11R6/lib/modules/extensions libGLcore.a.distrib # local diversion libglx.a.distrib# local diversion libglx.so - libglx.so.1.0.5# from nvidia libglx.so.1.0.5 # from nvidia /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia /usr/lib libGLcore.so - libGLcore.so.1 # from nvidia libGLcore.so.1 - libGLcore.so.1.0.5# from nvidia libGLcore.so.1.0.5 # from nvidia libGL.so - libGL.so.1 # here comes the problematic one libGL.so.1 - libGL.so.1.2 libGL.so.1.0.5 # from nvidia libGL.so.1.2# xlibmesa3 xlibmesa3 provides libGL.so.1.2 and something insist on libGL.so.1 pointing to it. I tried to divert the link, so that my link (libGL.so.1 - libGL.so.1.0.5) is not delete by xlibmesa3. This works fine during package install, but as soon as ldconfig is called, my link is replace by libGL.so.1 - libGL.so.1.2. How can I stop this? Is there a better approach of integrating the vendor supplied drivers? regards ff -- Florian Friesdorf [EMAIL PROTECTED] OpenPGP key available on public key servers -- Save the future of Open Source -- - Online-Petition against Software Patents - -- http://petition.eurolinux.org --- pgph23LMlBLVg.pgp Description: PGP signature
Re: how to deal with nvidia driver/libs
On Thu, Oct 12, 2000 at 03:06:17AM +0200, Florian Friesdorf wrote: I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. so far I have solved the following conflicts with dpkg-divert. /usr/X11R6/lib/modules/extensions libGLcore.a.distrib # local diversion really no need to divert this... libglx.a.distrib# local diversion this diversion can be avoided by specifying the full path to the libglx.so in the configuration file. /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia no need for this diversion either since they are different names (you just use nvidia instead of nv in the config file). /usr/lib [snip] # here comes the problematic one libGL.so.1 - libGL.so.1.2 libGL.so.1.0.5 # from nvidia libGL.so.1.2# xlibmesa3 xlibmesa3 provides libGL.so.1.2 and something insist on libGL.so.1 pointing to it. I tried to divert the link, so that my link (libGL.so.1 - libGL.so.1.0.5) is not delete by xlibmesa3. This works fine during package install, but as soon as ldconfig is called, my link is replace by libGL.so.1 - libGL.so.1.2. How can I stop this? for a quick fix if you change the divert-to name to something like: 'distrib.libGL.so.1.2' or anything that changes the name from having 'lib' as the first part of the filename the dynamic linker won't load it automatically and you should be safe from ldconfig changing the symlink on you. Is there a better approach of integrating the vendor supplied drivers? my solution was to put together all the necessary components and generate .deb packages for them which has 'Provides: libgl1' so that all dependencies are met and I don't need to go around dpkg-divert'ing everything (which was how I started when first testing out the drivers). Marc
Re: how to deal with nvidia driver/libs
Hi Marc, thanks for the fast reply. On Wed, Oct 11, 2000 at 06:52:48PM -0700, Marc Martinez wrote: On Thu, Oct 12, 2000 at 03:06:17AM +0200, Florian Friesdorf wrote: I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. libglx.a.distrib# local diversion this diversion can be avoided by specifying the full path to the libglx.so in the configuration file. that's good to know. /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia no need for this diversion either since they are different names (you just use nvidia instead of nv in the config file). I diverted nv, because of xf86cfg failing to start, because of to conflicting drivers. for a quick fix if you change the divert-to name to something like: 'distrib.libGL.so.1.2' or anything that changes the name from having 'lib' as the first part of the filename the dynamic linker won't load it automatically and you should be safe from ldconfig changing the symlink on you. that's also good to know. Is there a better approach of integrating the vendor supplied drivers? my solution was to put together all the necessary components and generate .deb packages for them which has 'Provides: libgl1' so that all dependencies are met and I don't need to go around dpkg-divert'ing everything (which was how I started when first testing out the drivers). Ok, then I will have a look at the packaging manual. regards ff -- Florian Friesdorf [EMAIL PROTECTED] OpenPGP key available on public key servers -- Save the future of Open Source -- - Online-Petition against Software Patents - -- http://petition.eurolinux.org --- pgpSJevd3ZAGU.pgp Description: PGP signature
Re: how to deal with nvidia driver/libs
On Thu, Oct 12, 2000 at 04:10:10AM +0200, Florian Friesdorf wrote: I diverted nv, because of xf86cfg failing to start, because of to conflicting drivers. ahh, I went through the config with the stock drivers before even extracting the nvidia stuff just to make sure the shipping defaults would at least get me a usable display. afterwards it was just a couple of tweaks in the config file and nvidia's driver was humming along happily.. Ok, then I will have a look at the packaging manual. as a final note, the recipe I used to cook my stuff up was to start with: for the -GLX package I started with debhelper (hadn't used it for any personal packages yet and was curious about what it was like from an initial packaging point of view) and used the ROOT variable in nvidia's Makefile to install the necessary files in the debian/tmp dir .. added in the docs and removed the _drv.o file from the dh_shlibdeps call .. after that was just the standard stuff of filling out the control file and changelogs and such. the second step was to create a framework for the module, my solution there was to start with the source tree that device3dfx installs and use that structure as the start of a sourcetree for the nvidia module component. this way a 'make-kpkg kernel-image modules-image' builds everything necessary and I don't hafta remember to go back out and build the module seperately before rebooting.. hopefully the notes above will help you and anybody else interested in building custom .deb's for these drivers make your own packages.. Marc
