Re: [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

Re: [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Richard Sandiford]

"Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr> writes:
> 2010-11-05  Pierre Muller  <muller@ics.u-strasbg.fr>
>
>                 * emultempl/spuelf.em (new_tmp_file): Fix wrong first
> parameter.

Applied, thanks.

Richard

Not in 2.21 sources... [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Pierre Muller]

  Hi all,

  I just tested compilation of 2.21 release for mingw
with  --enable-targets=all option
and I noticed that the fix that I submitted and
which was applied by Richard is not in 2.21 sources.

  I suppose it is because the 2.21 branch was created before November 5.

  I don't know if 2.21.1 will ever exist, but
merging that commit to 2.21 branch can't hurt anyhow.


Pierre Muller

> -----Message d'origine-----
> De : binutils-owner@sourceware.org [mailto:binutils-
> owner@sourceware.org] De la part de Richard Sandiford
> Envoyé : vendredi 5 novembre 2010 18:21
> À : Pierre Muller
> Cc : binutils@sourceware.org
> Objet : Re: [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on
> systems where HAVE_MKSTEMP is not defined
> 
> "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr> writes:
> > 2010-11-05  Pierre Muller  <muller@ics.u-strasbg.fr>
> >
> >                 * emultempl/spuelf.em (new_tmp_file): Fix wrong first
> > parameter.
> 
> Applied, thanks.
> 
> Richard

Re: Not in 2.21 sources... [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Tristan Gingold]

On Dec 9, 2010, at 12:10 PM, Pierre Muller wrote:

>  Hi all,
> 
>  I just tested compilation of 2.21 release for mingw
> with  --enable-targets=all option
> and I noticed that the fix that I submitted and
> which was applied by Richard is not in 2.21 sources.
> 
>  I suppose it is because the 2.21 branch was created before November 5.
> 
>  I don't know if 2.21.1 will ever exist, but
> merging that commit to 2.21 branch can't hurt anyhow.

Can you find the commit message in the archive ?  With it, I can take care of merging it.

Tristan.

RE: Not in 2.21 sources... [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Pierre Muller]

> Can you find the commit message in the archive ?  With it, I can take
> care of merging it.
> 
> Tristan.

 It's here:

http://sourceware.org/ml/binutils-cvs/2010-11/msg00041.html

  I got one second problem for compilation of ld
for mingw with --enable-targets=all
also in emultempl/spuelf.em
about the type of execvp argument #2
(char *const *)
type is given line 399, but
mingw process.h header
gives
(const char *const *)

which results in a warning, turned into an error
because -Werror is the default.

  I tried to look up what the correct type should be,
but didn't find any real unambiguous definition of that
function.

Pierre Muller

Re: Not in 2.21 sources... [OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Tristan Gingold]

On Dec 9, 2010, at 1:25 PM, Pierre Muller wrote:

>> Can you find the commit message in the archive ?  With it, I can take
>> care of merging it.
>> 
>> Tristan.
> 
> It's here:
> 
> http://sourceware.org/ml/binutils-cvs/2010-11/msg00041.html

Ok, backported.

Tristan.

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

[Pierre Muller]

This problem is still present in binutis-2.22 sources
compilation with --enable-targets=all for mingw32 target fails
due to a warning:
gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.22/ld  -I.
-I../../binutils-2.22/ld -
I../bfd -I../../binutils-2.22/ld/../bfd -I../../binutils-2.22/ld/../include
-g
-O0 -D__USE_MINGW_ACCESS -DENABLE_PLUGINS
-DLOCALEDIR="\"/usr/local/share/locale
\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wno-format
-Wer
ror -g -O0 -D__USE_MINGW_ACCESS -MT eelf32_spu.o -MD -MP -MF
.deps/eelf32_spu.Tp
o -c -o eelf32_spu.o \
          -DEMBEDSPU="\"`echo embedspu | sed 's/^ld-new$/ld.bfd/;s,y,y,'`\""
eel
f32_spu.c
cc1.exe: warnings being treated as errors
eelf32_spu.c: In function 'spu_elf_relink':
eelf32_spu.c:594:3: error: passing argument 2 of 'execvp' from incompatible
poin
ter type
e:\msys\mingw32\bin\../lib/gcc/mingw32/4.5.2/../../../../include/process.h:1
20:4
2: note: expected 'const char * const*' but argument is of type 'char *
const*'
make[3]: *** [eelf32_spu.o] Error 1


From http://sourceware.org/ml/binutils/2010-12/msg00337.html
>   I got one second problem for compilation of ld
> for mingw with --enable-targets=all
> also in emultempl/spuelf.em
> about the type of execvp argument #2
> (char *const *)
> type is given line 399, but
> mingw process.h header
> gives
> (const char *const *)
> 
> which results in a warning, turned into an error
> because -Werror is the default.
> 
>   I tried to look up what the correct type should be,
> but didn't find any real unambiguous definition of that
> function.
> 
> Pierre Muller


  I got no comment on that part of the email back then, and I still don't
know if this should be considered as an error in mingw32 declarations
or if it should be fixed in Binutils sources.

 I would like to know if this warning should be corrected or not...

  To be honest, I don't understand the difference between
'const char * const *' and 'char * const *' types anyway...

Pierre Muller
GDB pascal language maintainer

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

[nick clifton]

Hi Pierre,

>    To be honest, I don't understand the difference between
> 'const char * const *' and 'char * const *' types anyway...

I get confused by this sort of thing as well.  I think that correct 
interpretation is:

"const char * const *" is a fixed pointer to a fixed pointer to a byte.

"char * const *" is a fixed pointer to a modifiable pointer to a byte.


 > 2: note: expected 'const char * const*' but argument is of type 'char 
 > * const*'
 > make[3]: *** [eelf32_spu.o] Error 1
[...]
 >  I got no comment on that part of the email back then, and I still
 > don't know if this should be considered as an error in mingw32
 > declarations or if it should be fixed in Binutils sources.
 >
 > I would like to know if this warning should be corrected or not...

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.

Cheers
   Nick

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

[Pedro Alves]

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

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On 11/26/2011 00:39, nick clifton wrote:
>>  I got no comment on that part of the email back then, and I still
>> don't know if this should be considered as an error in mingw32
>> declarations or if it should be fixed in Binutils sources.
>>
>> I would like to know if this warning should be corrected or not...
> 
> 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.
> 

Before the misinformation spreads, see MSDN docs at:
<http://msdn.microsoft.com/en-us/library/3xw6zy53%28v=vs.80%29.aspx>.

intptr_t _execvp(
   const char *cmdname,
   const char *const *argv
);

execvp is an alias to _execvp. POSIX or not, MinGW can't change that
without annoying their target audience.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

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

[nick clifton]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Hi Pedro, Hi Pierre, Hi Alan,

> 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.

How about the attached patch ... any objections ?

Cheers
   Nick

2011-11-29  Nick Clifton  <nickc@redhat.com>

	* emultempl/spuelf.em (spu_elf_relink): Use pex_one instead of
	execvp.



[-- Attachment #2: spuelf.em.patch --]
[-- Type: text/plain, Size: 1135 bytes --]

Index: ld/emultempl/spuelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/spuelf.em,v
retrieving revision 1.43
diff -u -3 -p -r1.43 spuelf.em
--- ld/emultempl/spuelf.em	13 Jan 2011 13:06:22 -0000	1.43
+++ ld/emultempl/spuelf.em	29 Nov 2011 12:36:02 -0000
@@ -384,9 +384,13 @@ spu_elf_open_overlay_script (void)
   return script;
 }
 
+#include <errno.h>
+
 static void
 spu_elf_relink (void)
 {
+  const char *pex_return;
+  int status;
   char **argv = xmalloc ((my_argc + 4) * sizeof (*argv));
 
   memcpy (argv, my_argv, my_argc * sizeof (*argv));
@@ -397,9 +401,16 @@ spu_elf_relink (void)
   argv[my_argc++] = "-T";
   argv[my_argc++] = auto_overlay_file;
   argv[my_argc] = 0;
-  execvp (argv[0], (char *const *) argv);
-  perror (argv[0]);
-  _exit (127);
+
+  pex_return = pex_one (PEX_SEARCH | PEX_LAST, (const char *) argv[0],
+			(char * const *) argv, (const char *) argv[0],
+			NULL, NULL, & status, & errno);
+  if (pex_return != NULL)
+    {
+      perror (pex_return);
+      _exit (127);
+    }
+  exit (status);
 }
 
 /* Final emulation specific call.  */

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

[Alan Modra]

On Tue, Nov 29, 2011 at 12:42:05PM +0000, nick clifton wrote:
> How about the attached patch ... any objections ?

Assuming it works, none from me.  Thanks!

-- 
Alan Modra
Australia Development Lab, IBM

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

[nick clifton]

Hi Alan,

>> How about the attached patch ... any objections ?
>
> Assuming it works, none from me.

Ah - I think that I have done the right thing, but I am not sure.  Can 
you tell me how to trigger the spu_elf_relink() function ?  Do I need a 
native spu system ?

Cheers
   Nick

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

[Alan Modra]

Hi Nick,

On Tue, Nov 29, 2011 at 04:25:20PM +0000, nick clifton wrote:
> Can you tell me how to trigger the spu_elf_relink() function ?  Do I
> need a native spu system ?

ld-spu/icache1 will test it for you, any host will do.

-- 
Alan Modra
Australia Development Lab, IBM

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

[nick clifton]

Hi Guys,

> ld-spu/icache1 will test it for you, any host will do.

Well - that passes, so I have checked the patch in.

Cheers
   Nick

ld/ChangeLog
2011-12-01  Nick Clifton  <nickc@redhat.com>

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

[OBV/RFA] Fix compilation of ld/emultempl/spuelf.em on systems where HAVE_MKSTEMP is not defined

[Pierre Muller]

  mingw64 cross compilation gave me that error :

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../src/ld  -I.
-I../../src/ld -I../bfd -I../../src/ld/../bfd -I../../src/ld/../include
-I./../intl  -gstabs+ -O0 -D__USE_MINGW_ACCESS -DENABLE_PLUGINS
-DLOCALEDIR="\"/usr/local/share/locale\""   -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wshadow -Wno-format –Werror -gstabs+ -O0
-D__USE_MINGW_ACCESS -MT eelf32_spu.o -MD -MP -MF .deps/eelf32_spu .Tpo -c
-o eelf32_spu.o \
          -DEMBEDSPU="\"`echo embedspu | sed 's/^ld-new$/ld/;s,y,y,'`\""
eelf32_spu.c
cc1: warnings being treated as errors
../../src/ld/emultempl/spuelf.em: In function ‘new_tmp_file’:
../../src/ld/emultempl/spuelf.em:358:3: error: passing argument 1 of ‘open’
from
 incompatible pointer type
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:340:15: note: expected
‘cons
t char *’ but argument is of type ‘char **’

  The patch below fixes that compilation failure.
Is this OK?

Pierre

2010-11-05  Pierre Muller  <muller@ics.u-strasbg.fr>

                * emultempl/spuelf.em (new_tmp_file): Fix wrong first
parameter.

Index: emultempl/spuelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/spuelf.em,v
retrieving revision 1.41
diff -u -p -r1.41 spuelf.em
--- emultempl/spuelf.em            10 Aug 2009 07:50:56 -0000         1.41
+++ emultempl/spuelf.em         5 Nov 2010 11:18:46 -0000
@@ -355,7 +355,7 @@ new_tmp_file (char **fname)
   *fname = mktemp (*fname);
   if (*fname == NULL)
     return -1;
-  fd = open (fname, O_RDWR | O_CREAT | O_EXCL, 0600);
+  fd = open (*fname, O_RDWR | O_CREAT | O_EXCL, 0600);
 #endif
   return fd;
 }