Dear Wolfgang,
On Wed, Sep 10, 2008 at 7:32 AM, Wolfgang Denk wd@denx.de wrote:
Dear "Graeme Russ",
In message d66caabb0809090408l32562cfch7672814b944dbede@mail.gmail.com you wrote:
Including <asm/string.h> seems bogus to me as this is already done in <linux/string.h> which is included just two lines above. Please check.
I've rechecked, but removing this include results in an implicit declaration of function 'strncpy' on line 401 of /include/image.h
But this makes no sense to me. That's the relevant code from "include/linux/string.h":
18 /* 19 * Include machine specific inline routines 20 */ 21 #include <asm/string.h> 22 23 #ifndef __HAVE_ARCH_STRCPY 24 extern char * strcpy(char *,const char *); 25 #endif 26 #ifndef __HAVE_ARCH_STRNCPY 27 extern char * strncpy(char *,const char *, __kernel_size_t); 28 #endif
You include <linux/string.h>, which in turn unconditionally includes <asm/string.h>, so including <asm/string.h> another time in makes no sense to me.
Can you please dig a bit deeper what's happening there? "gcc -E" might help...
OK, I've found the source of the confusion...
The warning occurs when compiling /examples/82559_eeprom.c (which is only built for i386 architectures). This file #defines _PPC_STRING_H_ and _LINUX_STRING_H_. It is the #define _LINUX_STRING_H_ which prevents the entire /include/linux/string.h from being processed, and hence the necessity to include /include/asm/string.h
I don't know why _PPC_STRING_H_ is #defined - The only attachment to _PPC_STRING_H_ is the OXC board (PPC platform) which uses eepro100_eeprom.c which, according to lines 130-135 of /examples/Makefile is '# Utility for resetting i82559 EEPROM', BUT, eepro100_eeprom.c is not built for i386 and 82559_eeprom.c is not built for PPC
So I guess it gets more confusing, not less
Back to /examples/82559_eeprom.c - If I remove #define _LINUX_STRING_H_ from 82559_eeprom.c and the extra /include/asm/string.h from /include/image.h, Make all succeeds with only an ld warning (cannot find entry symbol 82559_eeprom; defaulting to 0000000000040000)
Should I re-pull (rebase? - sorry, not up with all the lingo yet) the master git repository, check the patch (with above changes) applies cleanly and resubmit (after checking my email client) or does this all warrant a closer inspection?
Also remember that I have had to disable SATA and PCI for the sc520_cdp as mentioned previously and my primary interest is not in the sc520_cdp (I don't own one, so I can't test this build) but rather another sc520 based product I am trying to port linux to.
Regards,
Graeme