This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC] 2.22 release: Compilation failure for mingw32 target with --enable-targets=all
- From: Pedro Alves <pedro at codesourcery dot com>
- To: binutils at sourceware dot org
- Cc: nick clifton <nickc at redhat dot com>, Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Date: Fri, 25 Nov 2011 17:02:16 +0000
- Subject: Re: [RFC] 2.22 release: Compilation failure for mingw32 target with --enable-targets=all
- References: <48683.3413750448$1288971470@news.gmane.org> <001201cca92b$0e9fbfe0$2bdf3fa0$@muller@ics-cnrs.unistra.fr> <4ECFC4CD.8030404@redhat.com>
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 <thilo.fischer@uni-muenster.de>
* 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