#134 closed defect (invalid)
gfortran is still not working on some linux machines
Reported by: | Juergen Reuter | Owned by: | ALL |
---|---|---|---|
Priority: | P1 | Milestone: | |
Component: | core | Version: | 2.0.0beta |
Severity: | blocker | Keywords: | |
Cc: |
Description
It seems that the old, old ticket (color flow problem!) has reopened again for gfortran, at least on 32 bit Linux. More details soon. This is the over-killer!
Change History (8)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
On demand of CS this is the anamnese of that error. Running the test_alpha_s script, we get:
libtool: link: (cd ".libs" && rm -f "processes.so.0" && ln -s "processes.so.0.0.0" "processes.so.0") libtool: link: (cd ".libs" && rm -f "processes.so" && ln -s "processes.so.0.0.0" "processes.so") libtool: link: ar cru .libs/processes.a ugug.o processes.o libtool: link: ranlib .libs/processes.a libtool: link: ( cd ".libs" && rm -f "processes.la" && ln -s "../processes.la" "processes.la" ) | Loading process library 'processes' | Process 'ugug': updating previous configuration sqrts = 500.00000000000000 Beam data (collision): u (mass = 0.0000000 GeV) gl (mass = 0.0000000 GeV) sqrts = 500.000000000000 GeV | Integrating process 'ugug' [c(-3 ) c(1 -2) c(2 ) ] *** WHIZARD bug: Color flow mismatch (color loops should be closed) WHIZARD run aborted.
In ancient times, this was a bug in some array functions in gfortran, does anyone remember!? Is anyone still alive?
comment:3 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm awfully sorry, this was an ancient library from an LHAPDF installation which got intruded into the main system libraries of WHIZARD. With the new(er) library of gfortran the color bug is gone. Closing.
comment:4 Changed 15 years ago by
Component: | configure → core |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Summary: | gfortran is not working on 32 bit machines → gfortran is still not working on some linux machines |
Sorry, this is not fixed:
with (it doesn't get much more recent)
ohl@wthp058:~whizard$ /archive/ohl/tools64/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20100117 (experimental)
I get on
Linux wthp058 2.6.26-2-amd64
the following
[ c(1 ) c(1 )] *** WHIZARD bug: Color flow mismatch (color loops should be closed) WHIZARD run aborted. FAIL: whizard_test_colors.sh
and
[c(-2 ) c(1 ) c(1 ) c(-1 )] *** WHIZARD bug: Color flow mismatch (color loops should be closed) | There were no errors and 15 warning(s). WHIZARD run aborted. FAIL: whizard_test_modeltest.sh
comment:5 Changed 15 years ago by
... puzzled.
No problem with
GNU Fortran (GCC) 4.5.0 20100111 (experimental)
on AMD64
Linux kagel 2.6.27.37-0.1-default #1 SMP 2009-10-15 14:56:58 +0200 x86_64 x86_64 x86_64 GNU/Linux
I'll update to the most recent version and check again.
BTW: We are all using default options, i.e., -g -O2, right?
comment:7 Changed 15 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
This is a runtime library mismatch between different versions of libgfortran.so.3. I have doublechecked on wthp058 using the same toolchain as Thorsten, and it works find if LD_LIBRARY_PATH is set correctly, and fails if not. If all else fails, try LD_PRELOAD to force the correct libraries. Closing this :)
I JUST CONFIRMED THIS WITH TRUNK REVISION 156003 ON LINUX 32BIT (DEBIAN EDGE). IF THIS IS NOT SOLVED, THERE IS NO SENSE IN CONTUNUING.