On Tuesday 22 June 2004 10:54, Hannu Savolainen wrote: > This kind of "breaks" are not so fatal provided that there is some way to > detect them reliably. Usually it's possible to check LINUX_VERSION_CODE > and use different approaches depending on the kernel version. However > this doesn't always work because distribution vendors often back port > features from the newer kernels into their distribution kernels which > have older LINUX_VERSION_CODE. A better approach would be marking them > with #define HAVE_NEW_something in the header file that implements this > change. I believe we are seeing this kind of problems all the time. This is not just a kernel 'problem'. Just take a look at the autoconf info page and the tests that a portable program has to run. Of course the makers of (i.e.) glib could just try to find a source tree that would compile everywhere but they know that this is impossible so they have to run tests like : (warning: long list) checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for dgettext in libc... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for nl_langinfo... yes checking for nl_langinfo and CODESET... yes checking whether we are using the GNU C Library 2.1 or newer... yes checking for vasprintf... yes checking for unsetenv... yes checking for getc_unlocked... yes checking for C99 vsnprintf... yes checking for nl_langinfo (CODESET)... yes checking for OpenBSD strlcpy/strlcat... no checking for an implementation of va_copy()... yes checking for an implementation of __va_copy()... yes checking whether va_lists can be copied by value... yes checking for RTLD_GLOBAL brokenness... no checking for preceeding underscore in symbols... no checking for dlerror... yes checking size of pthread_t... 4 checking for pthread_attr_setstacksize... yes checking for minimal/maximal thread priority... sched_get_priority_min(SCHED_OTHER)/sched_get_priority_max(SCHED_OTHER) checking for posix yield function... sched_yield checking whether to use the PID niceness surrogate for thread priorities... yes checking size of pthread_mutex_t... 24 checking byte contents of PTHREAD_MUTEX_INITIALIZER... 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 checking value of POLLIN... 1 checking value of POLLOUT... 4 checking value of POLLPRI... 2 checking value of POLLERR... 8 checking value of POLLHUP... 16 checking value of POLLNVAL... 32 .. and many more .. I don't believe that your source code is more complex than theirs. Maybe the solution to your problem is as simple as 'info autoconf'. You know that there are more than one ways to compile kernel modules so you just have to test each one of them and see which one works. We're talking about no more than 30 minutes work. After that you may add another distro in the supported distributions list of your module. > Hannu <>