readlink.c compiling failed because of size_t

[Ralf Corsepius]

On Wed, 2007-04-25 at 14:02 -0500, Joel Sherrill wrote:
> ray wrote:
> > compiling failed in /cpukit/libcsupport/src/readlink.c
> > type mismatch for:
> >
> > int readlink(
> >   const char *pathname,
> >   char       *buf,
> >   int         bufsize
> > )
> >
> > This function declare in include/sys/unistd.h
> >
> > ssize_t _EXFUN(readlink, (const char *__path, char *__buf, size_t __buflen));
> >
> > it seems the size_t had changed in the new tool chain.  and I change readlink in /cpukit/libcsupport/src/readlink.c to
> > ssize_t readlink(
> >   const char *pathname,
> >   char       *buf,
> >   size_t     bufsize
> > )
> > Then everything is fine.
> >
> > I am using:
> > gcc-4.2 with patch gcc-core-4.2-20070221-rtems4.8-20070228.diff
> > newlib-1.15.0 with patch newlib-1.15.0-rtems4.8-20070413.diff
> > Target is arm-rtems4.8
> >
> > What might cause this?
> >
> >   
> Your RTEMS does not match your toolset.  Your newlib patch is
> dated 13 April and Ralf committed a change to readlink on 14 April
> to make the 3rd argument a size_t.
Exactly.

SUSv3 mandates the size_t'ed readlink. rtems4.8 + its toolchains have
been changed to reflect this change. rtems4.7 + its toolchains apply the
non-size_t'ed readlink. 

This is one of the small but quite significant incompatibilities between
rtems4.7 and rtems4.8 and their toolchains.

We can't change it in rtems4.7 and older without breaking the API, 
because it has been RTEMS's policy not to break the API.

Of cause, technically, we could back-port this particular change to
rtems4.7, should there be agreement on this topic, but ... this would
break the API.

I.e. at the moment, you'll have to use the rtems4.7-toolchains to build
rtems4.7 and the rtems4.8-toolchains for rtems4.8.

Ralf