Summary: | sysklogd compile fails with 2.6 headers | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matt Taylor <liverbugg> |
Component: | [OLD] Core system | Assignee: | Tim Yamin (RETIRED) <plasmaroo> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, plasmaroo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 31285 | ||
Bug Blocks: | |||
Attachments: | Initial header patch |
Description
Matt Taylor
2004-01-15 16:56:32 UTC
Phosphan, had a look yet? Ill only get to it in a few days. I've had a look at the source, and at the headers, and things look quite nasty. Firstly, your first problems occur with jiffies.h [ 2.4 " Why did it work? " reason: it wasn't there before... ]: although that can be fixed by doing some hacky types.h redefinitions. Then eventually you hit some problems on <linux/time.h> and <linux/types.h>: these can be resolved as well. You'll enter redefinition hell with <asm/siginfo.h> as well; but that can also be fixed, although the code is quite messy for that. I'll attach a diff for both the headers and the C file. It's messy, but it works - it's incompatible with 2.4 headers, or even 2.6 headers so I've #ifdef'ed sections out to make sure the right headers are being used. The problem is that even though I've managed to fix the headers, the whole thing needs rewriting for 2.6 as quite a few structures are just no longer there in 2.6: ``size'', ``get_kernel_syms'' and ``module_info'' are just some examples - if somebody could find me some API documentation for the new 2.6 module system I'd be happy to rewrite the code but I can't find anything so far so I'm stuck... Created attachment 24093 [details, diff]
Initial header patch
Err, got confused with names there it seems =) Anyhow a few issues: 1) Is '#include <asm/mach-generic/mach_mpspec.h>' the only way to fix that issue? 2) How about just using LINUX_VERSION_CODE, and not adding GENTOO_26_CODE? 3) This: -- -extern u64 jiffies_64; +extern unsigned long long jiffies_64; -- Won't it work with __u64? For the rest I cannot see another way, and it 1: I think so. It's a generic header; thus it should work properly. I think the way it's done in the kernel is to have the mach locations defined at maketime, but as mach-generic is generic and will probably always be there, I don't see any problems with it.
2: No; because that tests for our patchset that can happily compile and that it's OK to do those fixes; the kernel level is needed later on for one if the #ifndefs.
3: In fact, I think there is: shifting the __u64 code out of the "#ifdef KERNEL" and removing that __STRICT_ANSI__ as well [ not sure why it's there; it won't conflict with anything, I think ] for asm-* and changing u64 -> __u64 would probably do it.
> For the rest I cannot see another way, and it
4: Not sure what to reply to that, you forgot to finish your sentence. I'll try and get the sysklogd code a rewrite some time next week...
OK, fixed in CVS. Thanks. |