This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] 2.22 release: Compilation failure for mingw32 target with --enable-targets=all

On Friday 25 November 2011 16:39:41, nick clifton wrote:

> I guess that mingw32 is free to define system headers as it so chooses. 
>   If however it is attempting to be POSIX compatible then it should 
> follow the POSIX standard for the execvp() function and prototype it as:
>   int execvp(const char *path, char *const argv[]);
> Ie, the binutils are correct and mingw32 ought to be changed.  I suspect 
> however that the mingw32 project will not want to change their header, 
> so the best compromise would be to fix the binutils.
> You could change the cast in spu_elf_relink() to be "(void *)" but this 
> is rather hacky.  You could add a configure time test of the prototype 
> of execvp() and conditionalize the cast in spu_elf_relink to match the 
> required poitner type.  But this seems a bit heavy handed.  I am not 
> sure what is best really.

The best is not to use execvp in host independent code at all, but to
use libiberty's pex routines.  Windows doesn't really support exec;
I'm surprised execvp is actually declared in mingw32's headers.  Or
maybe you're building for msys, rather than mingw32?

2009-04-09  Thilo Fischer <>

        * emultempl/spuelf.em (embedded_spu_file): Use pex_one in place
        of fork/execvp.

this same file has already been corrected once in another function,
but for some reason, spu_elf_relink wasn't.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]