[BusyBox] Re: Is it a cross-compiler problem?

[Xiaogeng (Shawn) Jin]

dank at kegel.com wrote:

> Have a look at the busybox changlog.  They have accepted patches to address
> this for some of their source files on systems where PATH_MAX is strangely
> defined not in limits.h but in sys/param.h.  Here's the patch I use:
> http://www.kegel.com/linux/busybox_path_max.patch
> to get it to compile with Montavista Hard Hat Linux 2.0.
Dan,

I had no problem with HHL 2.0 to compile busybox-0.60.2 without your 
patch. So I guess it's a problem not on busybox but on systems with 
compiler (gcc) and libraries (glibc) configured not correctly, as you 
said, less standards-compliant, or even non-standards-compliant.

I know many guys here (e.g. bill, kai and you, etc.) have built the 
cross development toolchain 'successfully' by themselves and shared 
their experience here. They really help new guys like me a lot. But my 
question is "are the tool chains bulit compliant with standards?". I 
don't think it's a good way to patch applications just in order to use 
some non-standards-compliant tool chains to build them. Patching the 
tool chains is better just like Wolfgang did at ELDK.

I just looked at the source (those patches and spec files) that Wolfgang 
provide. Oh, well...they are too many and too complicated for me right 
now. I need more time to go through them. But obviously he did great job 
to provide us a free cross development tool chain. Many patches are 
dealing with ELDK-specific installation and working enviroment. Am I 
right? I'm trying to find out where those tiny but essential details 
are, as wolfgang mentioned.

Wolfgang always suggests me to use those free and exsitent tools. But I 
believe that there are still a lot of guys here who wants to know how. 
;) If we know how at one target, we might be able to build a tool chain 
at another target, for example, a totally new released CPU, PPC 440GP. 
Hopefully.....

> If ELDK doesn't need that, great, it's more standards-compliant.
It seems to me that HHL 2.0 doesn't need that either.

>>It seems to me that somehow
>>my cross gcc didn't define '_POSIX_SOURCE' or '_GNU_SOURCE', which is
>>supposed to be defined by user or compiler.
> 
> I think you can strike the '... or compiler' from that.  I haven't
> seen any compiler that defines those.
I don't know. The comment on <features.h> says that those macros will be 
defined by users or compiler.

- Shawn.