Fwd: Re: [pdf-devel] Build failure

[Stefan Husmann]

Hello,

I filed a bug to the gnupdf mailing list because of a build error I encountered 
there.
Now I created a patch to solve this, which is attached.

I was asked to send the patch to this list, because a gnulib file is effected.

Best Regards

Stefan

 Original-Nachricht 
Betreff: Re: [pdf-devel] Build failure
Datum: Fri, 12 Oct 2012 18:23:13 +0200
Von: Stefan Husmann 
An: pdf-de...@gnu.org

Am 06.07.2012 18:13, schrieb Stefan Husmann:

Hello,

under a recent Arch Linux, which comes with gcc 4.7.1, I get an error:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../src -march=x86-64 
-mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 
-D_FORTIFY_SOURCE=2 -MT fopen-safer.lo -MD -MP -MF .deps/fopen-safer.Tpo -c 
fopen-safer.c  -fPIC -DPIC -o .libs/fopen-safer.o
In file included from stdio-safer.h:20:0,
  from fopen-safer.c:22:
./stdio.h:1010:1: error: 'gets' undeclared here (not in a function)
make[3]: *** [fopen-safer.lo] Error 1
make[3]: Leaving directory 
`/home/haawda/paketierung/maintained_by_me/gnupdf-bzr/src/gnupdf-build/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/haawda/paketierung/maintained_by_me/gnupdf-bzr/src/gnupdf-build/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/haawda/paketierung/maintained_by_me/gnupdf-bzr/src/gnupdf-build/lib'
make: *** [all-recursive] Fehler 1
==> FEHLER: Ein Fehler geschah in build().

How is this fixable?

Best Regards Stefan




Hello,

the attached patch fixes this for me.

A similar issue in GNU coreutils and the discussion regarding this can be found 
here:
http://comments.gmane.org/gmane.comp.gnu.coreutils.general/2525

Best Regards Stefan

diff -Naur gnupdf/lib/stdio.in.h gnupdf.new/lib/stdio.in.h
--- gnupdf/lib/stdio.in.h	2012-07-06 17:27:54.0 +0200
+++ gnupdf.new/lib/stdio.in.h	2012-10-12 18:13:54.0 +0200
@@ -695,8 +695,10 @@
 /* It is very rare that the developer ever has full control of stdin,
so any use of gets warrants an unconditional warning.  Assume it is
always declared, since it is required by C89.  */
+#if HAVE_RAW_DECL_GETS
 _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
 #endif
+#endif
 
 
 #if @GNULIB_OBSTACK_PRINTF@ || @GNULIB_OBSTACK_PRINTF_POSIX@

Projects suffer from syntax error

[stefan-husmann]

Hello list,

I more or less often recompile sources for certain GNU projects, and
at least three projects fail to bootstrap with the same message (only
line numbers vary). They all pull subrepos from gnulib. The problem
seems to be that the autotools generate invald configure scripts.

texinfo: line 5904ff of configure:
for ac_arg in '' ac_prog_cc_stdc=c89
   ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89
do
  CC="$ac_save_CC $ac_arg"
  if ac_fn_c_try_compile "$LINENO"
then :
  ac_cv_prog_cc_c89=$ac_arg
fi
rm -f core conftest.err conftest.$ac_objext conftest.beam
  test "x$ac_cv_prog_cc_c89" != "xno" && break
done

octave:
../configure: line 7723: syntax error near unexpected token 
`ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
../configure: line 7723: ` 
ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'

bison:
./configure: line 6277: syntax error near unexpected token 
`ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
./configure: line 6277: `  
ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'

In both cases the corresponding configure scripts include the above invalid 
code.

Best Regards

Stefan Husmann