I have a creative modem. the driver is a source tarball. On some systems it works well and installs very easily using ./configure && make && make install.
However on some systems (linux distros) it simply doesn't compile. Can i make a binary or rpm package from the source that works on all systems? Thank u

I am assuming that this driver is a kernel module, in which case it is building against the kernel the machine is running at compile time. This means that once compiled, it cannot be used on any other kernel build. In other words, the driver is mated to that particular build environment.

Now, if the driver isn't a module, then you should be able to use it on another system as long as it is a relatively similar environment (same versions of core libraries, for example).

It's a module unless this is Martian technology.

There's no other way that a program can access the hardware directly but to be on the kernel land, and that implies being a kernel module (well, there's the option of FUSE, but that's mainly used for filesystems and the like).

So, no, you can't make a magic rpm. For a kernel module to be able to load its magic info needs to be *exactly* the same than this of the kernel. This means same kernel version, but also same gcc version.

If it doesn't build in a concrete distro it might be because:

1.- you don't have the kernel sources installed
2.- you did not configure them adequately or did not build them
3.- you installed the sources for a kernel that's not the same kernel you are running
4.- others that I can't recall right now

If you want to solve the actual problem (that's compiling the driver on the distros that it doesn't compile) you need to supply the error messages so we can figure out why it fails to compile.

EDIT. Also if there's no legal problem, supply a link to this module or whatever it is. Just to check that it's actually a module and not some other strange thing.

Not all drivers need to be kernel modules. If the modem is USB, for example, the driver would simply interface with it through libusb; there is no need to go to the kernel level.

Well, to a certain extent. It's a similar case to the FUSE stuff. At a given point, it needs to reach kernel level. With sane it's done via libusb, with ntfs or sshfs is done using fuse, but nonetheless it need support on the kernel side.

It's true that I did not think of libusb, though. But it's just an high level api which directly interacts with the usb kernel modules, so, the important work is still done in kernel land.

But yes, you are right. Whatever he's trying to compile can or cannot be a kernel module. That's why I insisted on seeing it, because there's no way to give accurate help until then.

Cheers.

Yes it IS a kernel module. My modem uses an ESS chipset, and this is the only driver. On slackware and zenwalk, it installs flawlessly, however on some distros (which have kernel source installed) like pclinux 2008, vector linux and kubuntu 8.04 it doesn't compile. Sometimes it complains about not finding "a proper UTS_RELEASE file", sometimes it can't find "the version.h" file, etc. The driver is here: http://tx.technion.ac.il/~raindel/ess_2.6-v0.4.tar.gz

The first thing I would check is that the kernel version is the same kernel version of those distro that DO work. External drivers are usually picky about kernel versions because the kernel changes quickly.

Another thing I'd check is that the kernel you are trying to compile against is not massively patched. Some binary distros seems like they enjoy crapping out the kernel sources. Some of them offer a vanilla-kernel or something similar which you could try.

Luckily the developer just released a new version that luckily works with all new kernels. Thanks everybody. I learned useful points from you. But my question is how built-in kernel device drivers work. How can the mentioned driver be built into the kernel so that the modem works out of the box?

You mean so that it is added to the mainline kernel? The driver would have to be approved for inclusion into the main kernel, which may or may not happen depending on the license the driver is released under.

According to the notes on the header of the .c file, it's gnu gpl 2, so it should be fine. But I doubt that you are the first to think about this. I would check the linux kernel mailing list archives. More than probably, some discussion about this has already taken place.

If you can't find anything conclusive, you can always try asking there.