Source: openmpi
Version: 1.4.2-3
Severity: serious

From my pbuilder build log:

...
depbase=`echo dt_module.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
        /bin/bash ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../ompi/datatype -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa   -I../../../.. -I../.. -
I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include    -DNDEBUG -Wall -g -O2 -finline-functions -fno-strict-aliasing -pthread -fvisibility=hidden -MT dt_module.lo -MD -MP -MF $depbase.Tpo -c -o dt_module.lo
../../../../ompi/datatype/dt_module.c &&\
        mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../ompi/datatype -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../.. -I../.. -I../../../../opal/include -I../../../../orte/include -
I../../../../ompi/include -DNDEBUG -Wall -g -O2 -finline-functions -fno-strict-aliasing -pthread -fvisibility=hidden -MT dt_module.lo -MD -MP -MF .deps/dt_module.Tpo -c ../../../../ompi/datatype/dt_module.c  -fPIC -DPIC -o
.libs/dt_module.o
../../../../ompi/datatype/dt_module.c:177: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:182: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:187: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:192: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:203: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:208: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:219: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:224: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:229: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:234: error: expected expression before ')' token
../../../../ompi/datatype/dt_module.c:250: error: expected expression before ')' token
make[3]: *** [dt_module.lo] Error 1
make[3]: Leaving directory `/tmp/buildd/openmpi-1.4.2/build/shared/ompi/datatype'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/buildd/openmpi-1.4.2/build/shared/ompi'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/buildd/openmpi-1.4.2/build/shared'
make: *** [build-shared-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

tags 592892 + patch
thanks

* Daniel Schepler | 2010-08-13 10:25:31 [-0700]:
 /* Size of Fortran 77 LOGICAL*1 */
 #define OMPI_SIZEOF_FORTRAN_LOGICAL1

which is set by OMPI_F77_CHECK defined in config/f77_check.m4. By now we
are in the middle of the hell. Lets go further.
That macro has the C default for $ofc_type_alignment and replace it with
the Fortran value in the macro OMPI_F77_GET_ALIGNMENT()
config/f77_get_alignment.m4.
The value should be set in third last line

| $2=AS_VAR_GET([type_var])

It was transformed earlier into
| ofc_type_alignment=$ompi_cv_f77_alignment_LOGICALp1
but become something totally differnt,

|ofc_type_alignment=`eval 'as_val=${'type_var'};$as_echo "$as_val"'`

After carefully replacing it with AS_VAR_COPY we get
| eval ofc_type_alignment=\$$as_type_var

which does the job for now. Puh. Now out quick!

Sebastian

clone 592892 -1
reassign -1 autoconf
retitle -1 AS_VAR_GET regression
tags -1 + upstream
thanks

[ http://bugs.debian.org/592892 ]

If I got above right, then I'm cloning this bug for Autoconf and
marking it as upstream bug; adding bug-autoconf in Cc:.

* Sebastian Andrzej Siewior wrote on Wed, Aug 18, 2010 at 04:53:44PM CEST:

Well, AS_VAR_GET is (intentionally) undocumented, so your use of
AS_VAR_COPY is the right thing to do (which is why I'll leave the
original bug for openmpi).  Still, this is a regression in upstream
Autoconf that I think should be fixed.  The issue is that '*' needs to
be translated to 'p' here and the string treated as literal here:

cat >configure.ac <<\EOF
AC_DEFUN([OMPI_F77_GET_ALIGNMENT],[
    AS_VAR_PUSHDEF([type_var], [ompi_cv_f77_alignment_$1])
    $2=AS_VAR_GET([type_var])
    AS_VAR_POPDEF([type_var])dnl
])

AC_INIT
OMPI_F77_GET_ALIGNMENT([LOGICAL*1], [result])
EOF

autoconf
tail configure

should contain a line like:
  result=$ompi_cv_f77_alignment_LOGICALp1

but instead has something like:
    as_type_var=`$as_echo "ompi_cv_f77_alignment_LOGICAL*1" | $as_tr_sh`
    result=`eval 'as_val=${'type_var'};$as_echo "$as_val"'`

Thanks,
Ralf

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

This smells like fallout from:

** The macros AS_TR_SH and AS_TR_CPP no longer expand their results.

in 2.66.  I tracked this down in another project the other day.  The other
project was using AR_TR_CPP directly to generate content which was
eventually passed into one of the autoheader macros (like AH_BOTTOM).

I'm not sure why this change was made, but it does seem to be breaking
assumptions made by real-world Autoconf macros.

found 593546 2.67-2
thanks

For the record: current sid version is affected, it worked with 2.65-4.

Sebastian

severity 593546 normal
thanks

To summarize my understanding, originally Daniel Schepler
<dschepler@gmail.com> reported this bug against openmpi.  Then
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> showed that
it was an Autoconf regression and patched openmpi to avoid the
problem.  Ralf Wildenhues <Ralf.Wildenhues@gmx.de> pointed out
that the patch also changed openmpi from using an undocumented
m4sh interface to using a documented one, but that it was still a
bug that should be fixed.

Based on these facts, my reading is that this is not a "serious"
severity bug, because software should not depend on the stability
of undocumented interfaces.  I do not think that much software
does depend on the interface in question; otherwise, there would
be more than one bug report about it.  Thus, I'm downgrading this
bug to "normal" severity (with this email).

If there were an upstream fix to this bug, I'd consider applying
it.  But based on a glance at the v2.67..v2.68 diffs, I don't
think there is an upstream fix yet.

If my analysis is wrong, let me know.

Thanks,

Ben.