Release build doesn't compile due to missing !NODEP!

[kilian]

I downloaded the 2.0.0 tarball, configured, and it doesn't compile.

The culprit is a missing !NODEP! at the end of this line in the beginning of decays.f90:

  use limits, only: MAX_TRIES_FOR_DECAY_CHAIN

How could this slip make distcheck?

I fixed it in the trunk [2302], but I leave this ticket open: we should decide whether we do an immediate update of 2.0.0, or wait for a new (patch?) release. The other important bug was #293.

[Juergen Reuter]

Details???? I never had this problem. Maybe its choking of the NAG compiler. gfortran works perfectly. And actually there was no real help for me in testing the distribution.

[Juergen Reuter]

No, the tarball compiles with NAG 5.2 (724) on 32bit Linux. The WHIZARD tests work, but the OMega tests trigger a NAG ICE:

nagfor -I../src  -g -c -o omega_interface.o  ../../../../src/omega/tests/omega_interface.f90
NAG Fortran Compiler Release 5.2(724)
Extension: ../../../../src/omega/tests/omega_interface.f90, line 32: Procedure pointer component NUMBER_PARTICLES_IN
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 33: Procedure pointer component NUMBER_PARTICLES_OUT
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 34: Procedure pointer component NUMBER_SPIN_STATES
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 35: Procedure pointer component SPIN_STATES
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 36: Procedure pointer component NUMBER_FLAVOR_STATES
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 37: Procedure pointer component FLAVOR_STATES
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 38: Procedure pointer component NUMBER_COLOR_INDICES
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 39: Procedure pointer component NUMBER_COLOR_FLOWS
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 40: Procedure pointer component COLOR_FLOWS
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 41: Procedure pointer component NUMBER_COLOR_FACTORS
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 42: Procedure pointer component COLOR_FACTORS
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 43: Procedure pointer component COLOR_SUM
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 44: Procedure pointer component NEW_EVENT
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 45: Procedure pointer component RESET_HELICITY_SELECTION
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 46: Procedure pointer component IS_ALLOWED
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 47: Procedure pointer component GET_AMPLITUDE
           detected at )@<end-of-statement>
Extension: ../../../../src/omega/tests/omega_interface.f90, line 52: ABSTRACT interface
           detected at <end-of-statement>@ABSTRACT
Panic: ../../../../src/omega/tests/omega_interface.f90: Unexpected cdtype (0) in upsinfo_cdtype
Internal Error -- please report this bug
Abort
make[6]: *** [omega_interface.o] Error 3
make[6]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src/omega/tests'
make[5]: *** [check-TESTS] Error 2
make[5]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src/omega/tests'
make[4]: *** [check-am] Error 2
make[4]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src/omega/tests'
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src/omega/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src/omega'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/localscratch/reuter/whizard-2.0.0/build/src'
make: *** [check-recursive] Error 1

So please, Sebastian, its time for another bug report.

Wolfgang, we nee the EXACT information about system configuration, OS, and compiler.

[Juergen Reuter]

It is also working for gfortran on 64bit Linux (SuSe?). Again, I remove the complete installation from the system paths, i.e. all libwhizard*, libomega*, all O'Mega binaries, all scripts and all include files. So there should be no interference. It is working. The only mismatch is then NAG on 64 bit Linux. WK? Infos?

[Juergen Reuter]

My suggestion would then be (if WK could confirm) since it is only one weird combo to document this on the WIKI and to put a patch there. After Sebastian (or Wolfgang) reported the NAG bug, we could close this ticket. (Plz try to reproduce the NAG ICE on 64bit)

[ohl]

No problem here, using the release tarball (downloaded from hepforge) and nagfor 5.2(724) on 64bit Debian:

ohl@thopad2:/scratch/ohl/whizard-2.0.0/_build_nag$ make check
...
=====================================================
All 20 tests behaved as expected (1 expected failure)
(1 test was not run)
...
ohl@thopad2:/scratch/ohl/whizard-2.0.0/_build_nag$ nagfor -v
NAG Fortran Compiler Release 5.2(724)
Warning: No files specified
ohl@thopad2:/scratch/ohl/whizard-2.0.0/_build_nag$ uname -a
Linux thopad2 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU/Linux

[sschmidt]

Replying to jr_reuter:

No, the tarball compiles with NAG 5.2 (724) on 32bit Linux. The WHIZARD tests work, but the OMega tests trigger a NAG ICE:
{{{
nagfor -I../src -g -c -o omega_interface.o ../../../../src/omega/tests/omega_interface.f90
...
}}}
So please, Sebastian, its time for another bug report.

No, it isn't. I may quote from an email by Ian Hounam of NAG:

The -g option in NAG Fortran is specifically for debugging with the upsf90 debugger, which we no longer support. Please use the -g90 option for debugging with dbx90 or gdb. (The reasons for this are historical.)

If you compile with -g90 instead of -g the error goes away.

[sschmidt]

Just noticed that the -g flag is set per default with nagfor -> #296

[kilian]

Well, I did this:

$ wget www.hepforge.org/whizard/archive/whizard/whizard-2.0.0.tar.gz
$ tar xzf whizard-2.0.0.tar.gz
$ cd whizard-2.0.0/
$ ./configure FC=gfortran45
$ make

Then I get soon

libtool: compile:  gfortran45 -I../misc -I../vamp -g -O2 -c processes.f90  -fPIC -o .libs/processes.o
libtool: compile:  gfortran45 -I../misc -I../vamp -g -O2 -c processes.f90 -o processes.o >/dev/null 2>&1
make[2]: *** No rule to make target `limits.lo', needed by `decays.lo'.  Stop.
make[2]: Leaving directory `/home/kilian/whizard/tmp/whizard-2.0.0/src/whizard-core'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kilian/whizard/tmp/whizard-2.0.0/src'
make: *** [all-recursive] Error 1

It happens both as-is and with --disable-noweb.

The problem may occur only if builddir and srcdir are identical. But this is what most users will do.

[sschmidt]

On my home computer I get the same error but strangely with r2302, the tarball works.
My home pc is Suse 64bit, GNU Fortran (GCC) 4.6.0 20100411 (experimental), tried with different and same srcdir and builddir, the trunk fails in both ways, the tarbal works both times.

[ohl]

Replying to sschmidt:

My home pc is Suse 64bit, GNU Fortran (GCC) 4.6.0 20100411 (experimental), tried with different and same srcdir and builddir, the trunk fails in both ways, the tarbal works both times.

For me, the tarball fails with $builddir=$srcdir and fails otherwise (gfortran 4.5, Debian, 64bit).

I've added a comment to the Wiki page on build problems.

My suggestion is to get rid of

include .depend

in the various Makefiles, which does not conform to automake's portability rules anyway. (I've invented the make rule with grep and sed more than 10 year ago, so let me be the first to say that it's time for its retirement from Makefiles ...)

Instead, we can use O'Mega's approach with a separate update script for the dependencies that are stored in Makefile.depend and included by automake. The minor disadvantage is that one might forget to run update before make dist, but the major advantage is that the Makefiles never have to modify the source directories.

[ohl]

Proper solution using AM_MAKE_INCLUDE in r2311.

[Juergen Reuter]

I think for the release 2.0.0 this properly documented. The only thing for the future is to implement this thoroughly also in the WHIZARD core.

[kilian]

I implemented Thorsten's method for the core. This should solve the issue, all dependencies are now generated at build time [2325].