Description of problem: [foo@localhost ~]$ paw++ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! LOCB/LOCF: address 0x7fff2719e35c exceeds the 32 bit address space or is not in the data segments This may result in program crash or incorrect results Therefore we will stop here !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Version-Release number of selected component (if applicable): paw-2006-11.fc7
Could you please verify that paw++ isn't linked dynamically with any cernlib library? In any case I see 2 potential explanations for this issue. The use of gfortran or the use of the RPMOPTFLAGS that g77 doesn't support. Unfortunately the cernlib package compiled against g77 hasn't been accepted :-\ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237579 it could have been interesting to test with paw++-g77 from that package, since it could also be something else.
$ ldd $(which paw++) libXbae.so.4 => /usr/lib64/libXbae.so.4 (0x0000003c3e600000) libXm.so.2 => /usr/lib64/libXm.so.2 (0x0000003c42e00000) libXaw.so.7 => /usr/lib64/libXaw.so.7 (0x0000003c41a00000) liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x0000003c43200000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x0000003c40a00000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaaacc6000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003c3be00000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003c3e200000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaaaf4a000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaab163000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab397000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c3fe00000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaab59c000) libXp.so.6 => /usr/lib64/libXp.so.6 (0x0000003c42400000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003c40200000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003c3fa00000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003c3ea00000) libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x0000003c3c200000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003c3f600000) libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x0000003c4fe00000) libblas.so.3 => /usr/lib64/atlas/libblas.so.3 (0x0000003c40e00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003c3da00000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003c3de00000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) Doesn't appear to be anything cernlib-ish linked dynamically.
Looks like to me that the simplest fix would be to use paw from the cernlib compiled with g77. This would certainly need adding yet another conditional to the spec file such that the compiler suffix may be set differently on utilities and on libraries. That way the utilities would come from the cernlib-g77 and the libraries installed with cernlib-devel would be the gfortran compiled libs.
Most likely possibility is that this failure is caused by one of these flags (maybe only with gfortran, though g77 don't accept all of them): -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 Unfortunately I don't have access to a x86_64 box. Could it be possible for you to rebuild on x86_64 without those flags and try to find out which one is causing the issue? The flags used during the compilation of fortran libs and programs (like paw++) are set line 787 of the spec file, by FC_OPTFLAGS="%{optflags}"
I make the cernlib-g77 submission block this bug, since using the utilities from the cernlib-g77 could solve this issue temporarily. But it won't solve it for real.
Building with FC_OPTFLAGS="-g" gives the same (well, similar) error: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! LOCB/LOCF: address 0x7fffc3593a7c exceeds the 32 bit address space or is not in the data segments This may result in program crash or incorrect results Therefore we will stop here !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Not sure why flags would make a difference, as: LOCB/LOCF: address 0x7fff2719e35c exceeds the 32 bit address space seems like an obviously bogus warning on x86_64; the address space *should* be > 32 bits.
That's strange because it used to work with g77, and Harald Vogt had a look at the gfortran x86_64 combination for paw. For information, you could have a look at: http://people.debian.org/~kmccarty/cernlib/faq.html#41
cernlib-g77 is now in devel; could you please try paw++-g77? And also please retry paw++, since it was rebuilt, maybe there is a compiler issue.
I would like to fix that for F8 test 3, could you please try paw++-g77, if it works I'll swap what provides paw.
paw++-g77 appears to work.
The main paw package is now built against g77, I will push through bodhi now.
cernlib-2006-20.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cernlib'
cernlib-g77-2006-20.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cernlib-g77'
Could you please retest paw++ now?
Works on rawhide with 2006-20.fc9 (sorry, all I have on this box at the moment.)
Would have been better on F8, but it is enough.
cernlib-g77-2006-20.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
cernlib-2006-20.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
There has been some improvements in 64 bit handling with gfortran in 2006-23 (in rawhide). Could you please install/update paw-gfortran and try paw++-gfortran or paw-gfortran?
As a side note, it seems that the failure came from a missing -fno-automatic in the gfortran build.
Both paw++-gfortran and paw-gfortran start OK in rawhide for me.
I had the same problem (same error message) when compiling and testing a tweaked version of the CERN code MAD. I included -fno-automatic in the gfortran build and the problem disappeared. Linux localhost.localdomain 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux. Thanks for the suggestion Patrice !