Cannot determine sys_call_table status. assuming it isn't exported
A quick look in /usr/src/linux gave me the impression (I'll double-check) that gentoo-dev-sources does export this. Shows up as "D" in my System.map.
Irrelevant. On 2.4, the method we use to detect whether a symbol is exported depends on CONFIG_MODVERISONS; otherwise it doesn't work. On 2.6, it doesn't work ever. In either case, if we can't tell if the symbol is exported at configure time, we have to (for now) assume it is not.
Note that this is mostly not a problem, as we now support an alternate user/kernel interface that does not require using our traditional syscall. However, for the moment you won't get PAG support if we can't find the sys_call_table.
On x86 there is the additional, closely related problem that aclocal.m4 has explicit code to make the config_modversions test fail on Linux 2.6. As a result, the build system sets MPS="SP MP", which may be right for Red Hat but breaks on Gentoo.
The problem here is that we're using CONFIG_MODVERSIONS for two things: - To tell whether it is possible to tell if symbols are exported (the test works only if CONFIG_MODVERSIONS is set). On Linux 2.6, the test never works, so we pretend CONFIG_MODVERSIONS is not set.
- To tell whether it is safe/useful to build SP and MP modules from the same set of headers by setting different preprocessor macros (this works only if CONFIG_MODVERSIONS is not set). This actually has nothing to do with distributions -- it was safe and convenient in Linux 2.2 and 2.4. In Linux 2.6, it doesn't matter anyway because we use the kernel's build system, and you only get one module that way.
I agree that in a Linux 2.6 world, you don't want to set MPS="SP MP" based on CONFIG_MODVERSIONS; instead you always want to set it correctly based on the kernel you're building for.
Short-term, I'd go for patching the configure script in whatever way is appropriate for Gentoo. But maybe upstream should decouple the setting of MPS from the sys_call_table guesswork (and improve the heuristic for the latter, though that's perhaps more easily said than done).
You want mps_linux26-new.diff from ticket #15645.
Unfortunately, I was dumb and added that patch in a form that makes it not visible to the general public. I've attached a copy to this message.
As far as doing sys_call_table detection better...
There is little we can do at configure time to detect what symbols are exported by the kernel. In 2.4, we could check for the presence of the preprocessor macros which define the symbol versions for exported symbols, but only of CONFIG_MODVERSIONS was set. Because of changes in 2.6 in the build system and in how symbol versioning works, that is no longer possible. Lacking that, we have to take a conservative approach and assume the symbol is not exported. It's not really much of a heuristic.
On the positive side, the in-kernel module loader in 2.6 handles weak symbol references. So, I'm working on a mechanism that will allow us to do the best we can at finding the syscall table based on what symbols are exported _at run time_.
compile_et.o(.text+0xcb2): In function `yyerror': :undefined reference to `yylineno'
Haven't seen that one, sorry.
IIRC this is known lossage resulting from a change in flex. I don't recall what the workaround is, but I'm sure there are people reading who do.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
mps_linux26-new.diff
Description: Binary data