AVR32UC3B: newlib/syscalls.c: _execve_r(): Compilation problem

Dear RT-Thread community,

During the invocation of scons on the BSP for at32uc3b, the
compilation fails at syscalls.c. Here is the gist of the problem.

$ scons
scons: Reading SConscript files ...
Newlib version: 1.16.0
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build
CC build\kernel\components\libc\compilers\newlib\syscalls.o
C:\Skullets\rt-thread\rt-thread\components\libc\compilers\newlib\syscalls.c:118: error: conflicting types for '_execve_r'
c:\program files (x86)\atmel\avr tools\avr toolchain\bin\../lib/gcc/avr32/4.4.7/../../../../avr32/include/reent.h:65: note: previous declaration of '_execve_r' was here
scons: *** [build\kernel\components\libc\compilers\newlib\syscalls.o] Error 1
scons: building terminated because of errors.

For my tests, I just locally comment out the definition within
syscalls.c to get things moving. Other than returning "Operation not
supported", is there any other important use for this function?

Although I can't point at what I saw (sorry, I can't recall at this
moment - OR perhaps I am entirely mistaken), I remember an older
version of RT-Thread commenting this function out.

I even downloaded official release versions 5.0.0 and 4.1.1-beta to
check the state of the file. No luck. The function exists in both of
them.

I also tried maintaining the same signature for the function as is
declared in the reent.h header file.

int _execve_r(struct _reent *ptr, char * name, char **argv, char **env)
{
    ptr->_errno = ENOTSUP;
    return -1;
}

The above definition works with the build!

Could you please give me a hint for what the best way is to solve this
problem? Many thanks.

Start with components/libc/compilers/newlib/syscalls.c, especially the _execve_r definition around line 118, and compare it with the declaration in the AVR32 toolchain's reent.h. Run scons for the at32uc3b BSP to reproduce the conflicting-types error. Done means the BSP compiles without the _execve_r conflict while preserving the intended unsupported-operation behavior.