[BusyBox] Cross Compile: PATH_MAX undeclared
Magnus Damm
damm at opensource.se
Thu Nov 22 10:13:15 UTC 2001
gcc-2.95.3 does some tricks (not glibc as I said before, sorry).
have a look how gcc creates the file glimits.h
this is a snippet from my build-scripts:
# this will force gcc to create a limits.h that includes a libc-wrapper.
DID_LIMITS_H=
if [ ! -e $DIR/$pp/${target}/sys-include/limits.h ]; then
if [ ! -e $DIR/$pp/${target}/sys-include ]; then
mkdir -p $DIR/$pp/${target}/sys-include
fi
cp ../gcc/gcc/glimits.h $DIR/$pp/${target}/sys-include/limits.h
DID_LIMITS_H=yes
fi
target is ppc-linux and pp is usr in my case.
I've experienced several PATH_MAX problems before, but with this fix
everything is ok. I don't know if it's the right thing(tm) to do...
Cheers /
Magnus
Scott Murray wrote:
>
> On Thu, 22 Nov 2001, Steve Merrifield wrote:
>
> > Kam Lee wrote:
> > >
> > > I'm using gcc-2.95.3, glibc 2.2.3, basically I use Erik Mouw's cross-2.95.3.
> [snip]
> > I've come across a similar thing, but with mount.c and umount.c
> >
> > arm-linux-gcc -Wall -Wshadow -Os -fomit-frame-pointer -D_GNU_SOURCE
> > -DBB_VER='"0.60.2.pre"' -DBB_BT='"2001.11.22-09:51+0000"'
> > -DUSE_SYSTEM_PWD_GRP
> > -I. -c mount.c -o mount.o
> > mount.c: In function `mount_main':
> > mount.c:381: `PATH_MAX' undeclared (first use in this function)
> > mount.c:381: (Each undeclared identifier is reported only once
> > mount.c:381: for each function it appears in.)
> > make: *** [mount.o] Error 1
> >
> > In my toolset (RPMs from netwinder), PATH_MAX is defined in:
> > arm-linux/sys-include/linux/limits.h:
> > #define PATH_MAX 4095
> >
> > But the source is only including <limits.h>
> > Adding <linux/limits.h> fixes the problem :)
>
> That's the solution we've been using here at SOMA as well. When I
> looked into it, it seemed like a cross-compiler configuration issue.
> The hard-coded include search path in the cross gcc we build as part
> of our build process had it finding the limits.h in the directory
> $(prefix)/lib/gcc-lib/arm-linux/2.95.2/include first, and that one
> doesn't have an #include_next at the bottom for some reason. My
> attempts to fix this by playing with --with-headers and the like all
> failed, so I gave up investigating it until I had more time, which
> hasn't happened yet. If somebody has any useful ideas at to what
> we're doing wrong, I'm be willing to spend some time to experiment a
> bit more.
>
> Scott
>
> --
> Scott Murray
> SOMA Networks, Inc.
> Toronto, Ontario
> e-mail: scottm at somanetworks.com
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox
More information about the busybox
mailing list