richard offer wrote:
> What if your application contains some user code and a kernel module ?
> Want an obvious example ? X.
VMware is another. In such cases, they have to do the same as any other
system-specific packages: guess, or ask the user. Autoconf apps prefer
guessing; X uses Imake and would probably have the kernel source path
hard-coded in an Imake template :-)
The discussions here have suggested ways for a third-party module
package to guess how to install themselves, so that they will just work
on most systems. /lib/modules/`uname -r`/build is the best anyone's
come up with so far, and it does just work on "plain old" 2.4 systems.
/usr/src/linux-`uname -r` is the next best.
This fails in certain cases such as cross-compiling, when the kernel
isn't living in /usr/src or its not configured, and when it's not the
running kernel.
But then, this is true of userspace too. Build an app on a Red Hat
system, don't be surprised to find it fails to run on a Debian.
When cross-compiling a userspace app, you have to explicitly tell the
package how to build, libraries to use etc. whether by command line
flags or editing the source. That's the joy of
cross-compiling. /usr/lib doesn't contain the right libraries, but it's
ok for apps to look there _unless_ you say otherwise.
Same goes for kernel modules. /lib/modules/`uname -r`/build doesn't
contain the right files when cross-compiling, but it's ok for module
packages to look there _unless_ you say otherwise.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
