OK Dylan let's plow on!
On Apr 18, 2005, at 2:41 PM, Dylan wrote:
Derick,
I went through the kernel docs and then attempted to compile a custom kernel. I am using the stock kernel (2.4.20-8d...) that came with YDL. I first tried my own custom config and when I compiled it, I got an error:
make[1]: Entering directory `/usr/src/linux-2.4.20-8d/arch/ppc/platforms'
make all_targets
make[2]: Entering directory `/usr/src/linux-2.4.20-8d/arch/ppc/platforms'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-8d/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/usr/src/linux-2.4.20-8d/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=pmac_pic -c -o pmac_pic.o pmac_pic.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-8d/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/usr/src/linux-2.4.20-8d/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=pmac_setup -I/usr/src/linux-2.4.20-8d/drivers/scsi -I/usr/src/linux-2.4.20-8d/fs/partitions -I/usr/src/linux-2.4.20-8d/arch/ppc/mm -c -o pmac_setup.o pmac_setup.c
The compiler is telling you exactly what the problem is right here!
pmac_setup.c:675:44: macro "set_task_state" requires 2 arguments, but only 1 givenIn short, line 675 of the program called pmac_setup.c is the culprit. Because this is completely open source you can write your own correction to the code which here just means that you need to declare the function set_task_state and that is it! Until another error is run into. Of course, you really should know the C language very well and understand what you are declaring. If a function is unnecessary for your needs you could just comment it out, and then the compiler would compile the program picking up from where it left off, but again do you know enough C to read and understand what the code is doing or for that matter what it should NOT be doing?
pmac_setup.c: In function `pmac_discover_root':
pmac_setup.c:675: `set_task_state' undeclared (first use in this function)
pmac_setup.c:675: (Each undeclared identifier is reported only once
pmac_setup.c:675: for each function it appears in.)
This is one of those uncomfortable situations where either one knows or one doesn't and any other position is a waste of time. You could perhaps avoid this problem (to an extent) by choosing a kernel's source which is more current. I found the early 2.6 series quite robust and reliable. And far less buggy, which is really the whole point.
The modules which you may be looking to implement or utilize should be available at a higher kernel version than 2.4.20-8d and written better to boot (excuse the pun).
Remember that the module packages are themselves built up from just the same kind of code as whatever is in pmac_setup.c and if you see that kind of report from the compiler again understand that it (the compiler) is beckoning (calling upon your attention) so that you to correct it. It is assuming that you are a programmer it can seek help from; so find your inner C programmer and do what you can OR you could play it a bit more clever and find kernel source closer to what is current.
A bit of a hint ... programmers tend to work nearly universally on what is interesting and what is interesting (calling and demanding their full attention) is whatever is current. As a project becomes more and more associated with the past, the less importance that project has and the less of a return or utility, you as a user of that software will likely benefit from. This means that kernels of the 2.4 and 2.3 and earlier series are less likely to see any substantive correction, repair or change other than whatever you yourself make which of course you are obligated to clearly note and post for others via comments within the source (as well as notifying the software team of whatever changes you made) to review according to the GPL.
I ran into the same problem as you did sometime ago, and rewrote some kernel code also. I corrected errors similar to what you discovered and other declaration error problems such as confusion of type and so on. I do recall eventually following the advice I'm suggesting to you and moving up to a more current kernel version (then 2.6.x).
Best wishes....
_______________________________________________ yellowdog-general mailing list [email protected] http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
