Acknowledgement sent
to Daniel Schepler <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian Open MPI Maintainers <[email protected]>.
(Fri, 13 Aug 2010 17:27:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Sebastian Andrzej Siewior <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Open MPI Maintainers <[email protected]>.
(Wed, 18 Aug 2010 14:57:03 GMT) (full text, mbox, link).
tags 592892 + patch
thanks
* Daniel Schepler | 2010-08-13 10:25:31 [-0700]:
>Source: openmpi
>Version: 1.4.2-3
>Severity: serious
>
>../../../../ompi/datatype/dt_module.c:177: error: expected expression before ')' token
In Line 177 OMPI_ALIGNMENT_FORTRAN_LOGICAL1 is not really set, it is:
/* 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
Acknowledgement sent
to Ralf Wildenhues <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Open MPI Maintainers <[email protected]>.
(Wed, 18 Aug 2010 17:33:03 GMT) (full text, mbox, link).
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:
> 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!
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
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Open MPI Maintainers <[email protected]>.
(Thu, 19 Aug 2010 01:09:03 GMT) (full text, mbox, link).
Ralf Wildenhues <[email protected]> writes:
> 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"'`
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.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Changed Bug title to 'AS_VAR_GET regression' from 'openmpi: FTBFS: Compilation errors'
Request was from Ralf Wildenhues <[email protected]>
to [email protected].
(Thu, 19 Aug 2010 07:18:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Sebastian Andrzej Siewior <[email protected]>:
Extra info received and forwarded to list. Copy sent to Ben Pfaff <[email protected]>.
(Thu, 19 Aug 2010 17:21:04 GMT) (full text, mbox, link).
severity 593546 normal
thanks
To summarize my understanding, originally Daniel Schepler
<[email protected]> reported this bug against openmpi. Then
Sebastian Andrzej Siewior <[email protected]> showed that
it was an Autoconf regression and patched openmpi to avoid the
problem. Ralf Wildenhues <[email protected]> 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.
--
Ben Pfaff
http://benpfaff.org
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.