Link failure on systems lacking mkstemp

Link failure on systems lacking mkstemp

[Eli Zaretskii]

Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
own private version in libguile/.  This causes link failures on
systems, such as MinGW, that lack mkstemp in their system libraries:

       CCLD     libguile-2.0.la
     ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
     d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
     .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: first defined here
     collect2.exe: error: ld returned 1 exit status
     Makefile:2242: recipe for target `libguile-2.0.la' failed
     make[3]: *** [libguile-2.0.la] Error 1
     make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
     Makefile:2162: recipe for target `all' failed

I think the solution is simply remove mkstemp.c from libguile/, and
all its traces from the configury that causes its dependency to be
added to libguile/Makefile.  Not sure how to do the latter, though.

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

> Date: Sat, 16 Aug 2014 14:42:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I think the solution is simply remove mkstemp.c from libguile/, and
> all its traces from the configury that causes its dependency to be
> added to libguile/Makefile.  Not sure how to do the latter, though.

Actually, there's one small change that's required for using Gnulib's
mkstemp: it opens the temporary file in the (default) text I/O mode,
while we need it in binary mode, because we use these temporary files
for writing *.go files.  Here's the proposed patch:

+++ libguile/filesys.c	2014-08-16 17:44:35.578125000 +0300
@@ -1479,6 +1479,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 
   SCM_SYSCALL (rv = mkstemp (c_tmpl));
   if (rv == -1)
     SCM_SYSERROR;
+#ifdef __MINGW32__
+  /* Files created by this function are used for *.go files, so make
+     sure they use binary I/O, or else the produced *.go files will be
+     corrupted by end-of-line conversion and ^Z "software EOF"
+     misfeature.  Gnulib's 'mkstemp' uses the default text mode to
+     open the file .  */
+  _setmode (rv, _O_BINARY);
+#endif
 
   scm_substring_move_x (scm_from_locale_string (c_tmpl),
 			SCM_INUM0, scm_string_length (tmpl),

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

Ping!

> Date: Sat, 16 Aug 2014 17:49:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 16 Aug 2014 14:42:54 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > I think the solution is simply remove mkstemp.c from libguile/, and
> > all its traces from the configury that causes its dependency to be
> > added to libguile/Makefile.  Not sure how to do the latter, though.
> 
> Actually, there's one small change that's required for using Gnulib's
> mkstemp: it opens the temporary file in the (default) text I/O mode,
> while we need it in binary mode, because we use these temporary files
> for writing *.go files.  Here's the proposed patch:
> 
> +++ libguile/filesys.c	2014-08-16 17:44:35.578125000 +0300
> @@ -1479,6 +1479,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 
>    SCM_SYSCALL (rv = mkstemp (c_tmpl));
>    if (rv == -1)
>      SCM_SYSERROR;
> +#ifdef __MINGW32__
> +  /* Files created by this function are used for *.go files, so make
> +     sure they use binary I/O, or else the produced *.go files will be
> +     corrupted by end-of-line conversion and ^Z "software EOF"
> +     misfeature.  Gnulib's 'mkstemp' uses the default text mode to
> +     open the file .  */
> +  _setmode (rv, _O_BINARY);
> +#endif
>  
>    scm_substring_move_x (scm_from_locale_string (c_tmpl),
>  			SCM_INUM0, scm_string_length (tmpl),
> 
> 

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

Ping! (1 month)

> Date: Fri, 29 Aug 2014 11:30:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping!
> 
> > Date: Sat, 16 Aug 2014 17:49:10 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Date: Sat, 16 Aug 2014 14:42:54 +0300
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > I think the solution is simply remove mkstemp.c from libguile/, and
> > > all its traces from the configury that causes its dependency to be
> > > added to libguile/Makefile.  Not sure how to do the latter, though.
> > 
> > Actually, there's one small change that's required for using Gnulib's
> > mkstemp: it opens the temporary file in the (default) text I/O mode,
> > while we need it in binary mode, because we use these temporary files
> > for writing *.go files.  Here's the proposed patch:
> > 
> > +++ libguile/filesys.c	2014-08-16 17:44:35.578125000 +0300
> > @@ -1479,6 +1479,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 
> >    SCM_SYSCALL (rv = mkstemp (c_tmpl));
> >    if (rv == -1)
> >      SCM_SYSERROR;
> > +#ifdef __MINGW32__
> > +  /* Files created by this function are used for *.go files, so make
> > +     sure they use binary I/O, or else the produced *.go files will be
> > +     corrupted by end-of-line conversion and ^Z "software EOF"
> > +     misfeature.  Gnulib's 'mkstemp' uses the default text mode to
> > +     open the file .  */
> > +  _setmode (rv, _O_BINARY);
> > +#endif
> >  
> >    scm_substring_move_x (scm_from_locale_string (c_tmpl),
> >  			SCM_INUM0, scm_string_length (tmpl),
> > 
> > 
> 
> 

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

Ping!

> Date: Sat, 16 Aug 2014 14:42:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> own private version in libguile/.  This causes link failures on
> systems, such as MinGW, that lack mkstemp in their system libraries:
> 
>        CCLD     libguile-2.0.la
>      ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
>      d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
>      .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: first defined here
>      collect2.exe: error: ld returned 1 exit status
>      Makefile:2242: recipe for target `libguile-2.0.la' failed
>      make[3]: *** [libguile-2.0.la] Error 1
>      make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
>      Makefile:2162: recipe for target `all' failed
> 
> I think the solution is simply remove mkstemp.c from libguile/, and
> all its traces from the configury that causes its dependency to be
> added to libguile/Makefile.  Not sure how to do the latter, though.

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

Ping!  (1 month)

> Date: Fri, 29 Aug 2014 11:29:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping!
> 
> > Date: Sat, 16 Aug 2014 14:42:54 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> > own private version in libguile/.  This causes link failures on
> > systems, such as MinGW, that lack mkstemp in their system libraries:
> > 
> >        CCLD     libguile-2.0.la
> >      ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
> >      d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
> >      .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: first defined here
> >      collect2.exe: error: ld returned 1 exit status
> >      Makefile:2242: recipe for target `libguile-2.0.la' failed
> >      make[3]: *** [libguile-2.0.la] Error 1
> >      make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
> >      Makefile:2162: recipe for target `all' failed
> > 
> > I think the solution is simply remove mkstemp.c from libguile/, and
> > all its traces from the configury that causes its dependency to be
> > added to libguile/Makefile.  Not sure how to do the latter, though.
> 
> 

Re: Link failure on systems lacking mkstemp

[Ludovic Courtès]

Hello, Eli,

Eli Zaretskii <eliz@gnu.org> skribis:

> Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> own private version in libguile/.  This causes link failures on
> systems, such as MinGW, that lack mkstemp in their system libraries:
>
>        CCLD     libguile-2.0.la
>      ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
>      d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
>      .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: first defined here
>      collect2.exe: error: ld returned 1 exit status
>      Makefile:2242: recipe for target `libguile-2.0.la' failed
>      make[3]: *** [libguile-2.0.la] Error 1
>      make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
>      Makefile:2162: recipe for target `all' failed
>
> I think the solution is simply remove mkstemp.c from libguile/, and
> all its traces from the configury that causes its dependency to be
> added to libguile/Makefile.  Not sure how to do the latter, though.

I’m ashamed of the delay but hey, better late than never.

This bug was reported independently at <http://bugs.gnu.org/21425> and a
fix was committed just yesterday, along the lines of what you suggested
(see commit efd8a43.)  Let me know what you think.

Apologies for the lack of response!

Thank you,
Ludo’.

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: guile-devel <guile-devel@gnu.org>
> Date: Fri, 30 Oct 2015 15:53:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> skribis:
> 
> > Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> > own private version in libguile/.  This causes link failures on
> > systems, such as MinGW, that lack mkstemp in their system libraries:
> >
> >        CCLD     libguile-2.0.la
> >      ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
> >      d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
> >      .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: first defined here
> >      collect2.exe: error: ld returned 1 exit status
> >      Makefile:2242: recipe for target `libguile-2.0.la' failed
> >      make[3]: *** [libguile-2.0.la] Error 1
> >      make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
> >      Makefile:2162: recipe for target `all' failed
> >
> > I think the solution is simply remove mkstemp.c from libguile/, and
> > all its traces from the configury that causes its dependency to be
> > added to libguile/Makefile.  Not sure how to do the latter, though.
> 
> I’m ashamed of the delay but hey, better late than never.
> 
> This bug was reported independently at <http://bugs.gnu.org/21425> and a
> fix was committed just yesterday, along the lines of what you suggested
> (see commit efd8a43.)  Let me know what you think.

Thanks, looks good.