Re: uname blues
> From: Matt Brubeck <mbrubeck@hmc.edu>
>
> The issue of 'uname -pm' is separate, and I agree with you there.
Matt-
You are right. These are two separate issues.
- Regarding kernel -powermac appened in pre-compiled kernel images:
OK. I think I got it. I point my includes to the header files I downloaded
separately (kernel-headers) and then I get the correct version (the
version.h is correct.) BUT: if I compile a driver in my project using these
non-custom headers (with -I/usr/src/kernel-headers...) and then insmod the
built driver against this pre-compiled kernel I am using, I get an error
with version clashing still (which I made a warning by forcing the insmod to
ignore version for now.) This is still far from ideal. So unless I recompile
the kernel (which I can't do as it's buggy and doesn't even compile), I have
to either modify the version.h file, either ignore version when doing
insmod. Nothing fancy, I just want to follow what's in the Device Drivers
book from O'Reilly. And this doesn't work when I am on testing.
- Regarding the uname -p returning unknown:
What can I do to help resolve this issue? Right now, the kludge I have
implemented to get my makefiles to function on linux without changing
anything, let alone being able to use them cross-platform, is ugly at best
(I overload the bogus uname command on linux with a script that returns what
uname -m returns for uname -p. The script lives in a path that shows earlier
than /bin. Yuk!) I do that because I don't think it's right to change all my
makefiles. I could have tested uname -s then exec uname -m in case of linux,
or a uname -p if something else. Still Yuk! uname -p is far from being
unknown: it's the processor of the machine.
I have decided to report this as a bug to bug-sh-utils@gnu.org. Is that the
right thing to do? Your input is, as usual, greatly appreciated.
Laurent
Reply to: