• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Getting a nvidia x86_64 package into a ia32 userland

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
The nvidia drivers involve two separate components, one source, and one binary. The binary contains the bulk of the driver and is precompiled. The source part is the wrapper that makes the modules work with your kernel. It's basically a way of releasing closed source software that works with different kernel configurations.

The binary modules are different for 32 bit and 64 bit systems. They are not compatible. You cannot interface a 32 bit binary module with a 64 bit kernel, and vice versa. On the nVidia site, when you download the driver installers, you get either the 32 bit or the 64 bit version. They are quite different.

Userspace programs work somewhat differently from kernel modules, which must very closely match the kernel.

X.org or other userspace components shouldn't matter to kernel modules. The kernel is self-sufficient and does not dynamically link to any libraries. I have no idea why your system thinks it's 32 bit and won't build the 64 bit nvidia modules. I've built and successfully inserted nvidia modules on systems that don't even have X.org. I suspect you did not correctly set up multilib.
...or set it up at all...
 
Well as it turn out, I managed to extract the 64 bit object file I wanted, I managed to compile the wrapper for it for my kernel, and it boots, the module loads and is happy and all is well in 64 bits kernelland....but
xorg fails to load and interface with the driver. There must be some data that are not strongly typed in the bridge between the userland xorg and the underlying driver. Oh well. So back to lame PAE.

I'd like to thank the couple of people who were helpful with suggestions, and tell all the others to get a clue.

Huhu:
Are you sure that even works? I was not aware you could place environment variables after the command. I would think that would come up with an invalid make target error, as ARCH= and CC= should be environment variables.
Code:
ARCH=x86_64 CC=gcc-4.3 make whatevertargetyou'remaking
 
Define "huhu". If you meant "huh?", AFAIK environment variables (such as ARCH and CC) must always come first, before the command you're running. Like
Code:
USE="-x" emerge links
in Gentoo.

For what reason are you refusing to switch to a full 64-bit system?

I'd like to thank the couple of people who were helpful with suggestions, and tell all the others to get a clue.
Statements like that are definitely not going to help you.
 
Last edited:
Well as it turn out, I managed to extract the 64 bit object file I wanted, I managed to compile the wrapper for it for my kernel, and it boots, the module loads and is happy and all is well in 64 bits kernelland....but
xorg fails to load and interface with the driver. There must be some data that are not strongly typed in the bridge between the userland xorg and the underlying driver. Oh well. So back to lame PAE.
You'll probably need a 64-bit Xorg/supporting libraries, unfortunately.
 
Back