Alvaro Herrera escribió:
> Yessica Brinkmann escribió:
> > Buenas,
> > Bueno, probé los comandos tal y como me indicaron.
> > Y sigo teniendo el mismo error. La verdad que supongo que no es por la
> > versión del Debian, ya que según me indicaron a una persona le funciona
> > perfectamente. Pero no sé porqué yo sigo teniendo el mismo error.
> >
> > Volví incluso a descargar y descomprimir el Postgresql 8.3.23.
>
> Ah, ya sé lo que pasa -- te falta el último commit en 8.3 después de
> 8.3.23. Recomiendo hacer un clon con git en vez de usar el tarball, o
> bien puedes aplicar el parche directamente. Las antiguas versiones no
> funcionan con los gcc nuevos.
Aquí está el parche. Si tienes el tarball de 8.3.23, lo aplicas con
patch -p1 <
/path/al/0001-Disable-faggressive-loop-optimizations-in-gcc-4.8-fo.patch
y luego vuelves a ejecutar los pasos de instalación desde el configure en
adelante.
(Este parche existe precisamente porque una vez quise compilar 8.2 y 8.3
con gcc moderno y tenía el mismo problema que tú).
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From d13f41d2153890bf817451c152a83d2867e61199 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvhe...@alvh.no-ip.org>
Date: Tue, 20 Jan 2015 12:26:20 -0300
Subject: [PATCH] Disable -faggressive-loop-optimizations in gcc 4.8+ for
pre-9.2 branches.
With this optimization flag enabled, recent versions of gcc can generate
incorrect code that assumes variable-length arrays (such as oidvector)
are actually fixed-length because they're embedded in some larger struct.
The known instance of this problem was fixed in 9.2 and up by commit
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
actually-variable-length catalog fields from the compiler altogether.
And we plan to gradually convert variable-length fields to official
"flexible array member" notation over time, which should prevent this type
of bug from reappearing as gcc gets smarter. We're not going to try to
back-port those changes into older branches, though, so apply this
band-aid instead.
Andres Freund
This is a backpatch of commit 649839dd9 to unsupported branches
REL8_2_STABLE and REL8_3_STABLE, so that they work with newer toolsets.
---
configure | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
configure.in | 3 +++
2 files changed, 54 insertions(+)
diff --git a/configure b/configure
index 4683503332..5e49c4b3a8 100755
--- a/configure
+++ b/configure
@@ -3172,6 +3172,57 @@ echo "${ECHO_T}no" >&6
fi
rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ # Disable loop optimizations that get confused by variable-length struct
+ # declarations in gcc 4.8+
+ { echo "$as_me:$LINENO: checking if $CC supports
-fno-aggressive-loop-optimizations" >&5
+echo $ECHO_N "checking if $CC supports -fno-aggressive-loop-optimizations...
$ECHO_C" >&6; }
+pgac_save_CFLAGS=$CFLAGS
+CFLAGS="$pgac_save_CFLAGS -fno-aggressive-loop-optimizations"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try="$ac_compile"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+ (eval "$ac_compile") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest.$ac_objext; then
+ { echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6; }
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ CFLAGS="$pgac_save_CFLAGS"
+ { echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6; }
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
elif test "$ICC" = yes; then
# Intel's compiler has a bug/misoptimization in checking for
# division by NAN (NaN == 0), -mp1 fixes it, so add it to the CFLAGS.
diff --git a/configure.in b/configure.in
index 05ce677bfd..74ad34df40 100644
--- a/configure.in
+++ b/configure.in
@@ -294,6 +294,9 @@ if test "$GCC" = yes -a "$ICC" = no; then
PGAC_PROG_CC_CFLAGS_OPT([-fwrapv])
# Disable FP optimizations that cause various errors on gcc 4.5+ or maybe
4.6+
PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
+ # Disable loop optimizations that get confused by variable-length struct
+ # declarations in gcc 4.8+
+ PGAC_PROG_CC_CFLAGS_OPT([-fno-aggressive-loop-optimizations])
elif test "$ICC" = yes; then
# Intel's compiler has a bug/misoptimization in checking for
# division by NAN (NaN == 0), -mp1 fixes it, so add it to the CFLAGS.
--
2.11.0
