 |
SEARCH
TOOLBOX
LANGUAGES
Forum Menu
undefined reference to ' gfortran copy string'
From NWChem
Viewed 7709 times, With a total of 12 Posts
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 8:03:03 AM PDT - Sun, Aug 19th 2012 |
|
Trying to build NWChem-src-2012-Jul-25 on an AMD64 Linux machine running
Ubuntu 12.04. Using these envars: NWCHEM_TARGET=LINUX64,
NWCHEM_MODULES=all, and the make command `make FC=gfortran > & make.log`.
`configure` is apparently successful, and makes gets a lot done before
terminating with fatal error "ilaenv.f:(.text+0x71):
undefined reference to `_gfortran_copy_string'"
I can send the full make.log if that will help.
One interpretation of the INSTALL file would seem to be that with Linux86_64
only the pathf90, ifort, or pgf90 compilers work. But I had built v. 6.0 with gfortran,
and assume this is fairly standard.
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 11:01:09 AM PDT - Mon, Aug 20th 2012 |
|
Rwohlhueter,
Do you happen to have more than one gcc/gfortran compiler version installed on your linux computer?
A possible explanation of your problem is that you might have compiled the lapack directory with an older version of
gfortran, then relinked with a newer one. If this is the case, please try to do the following to see if
you can fix the problem
cd $NWCHEM_TOP/src/lapack
make clean
make FC=gfortran
cd ..
make FC=gfortran link
Cheers, Edo
|
|
|
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 5:10:09 PM PDT - Mon, Aug 20th 2012 |
|
Indeed, Synaptic showed that I had no less than three versions of gfortran installed, and God knows how compilier and libraries might have been mix-and-matched. But I uninstalled gfortran v4.4 and 4.5, reinstalled v. 4.6.3 [Now apparently the only version: gfortran --version -> GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.5.3]
Even so, when I clean, re-make, and re-make link (as you prescribe) I get precisely the same (ilaenv.f: undefined reference to '_gfortran_copy_string').
I had compiled, and still have a working NWCHEM 6.0. The NWCHEM website says binaries for 6.1 will be posted as they become available. Maybe the prudent thing to do is just to wait until you guys distribute the appropriate binary.)
Bob W.
Quote:Edoapra Aug 20th 6:01 pmRwohlhueter,
Do you happen to have more than one gcc/gfortran compiler version installed on your linux computer?
A possible explanation of your problem is that you might have compiled the lapack directory with an older version of
gfortran, then relinked with a newer one. If this is the case, please try to do the following to see if
you can fix the problem
cd $NWCHEM_TOP/src/lapack
make clean
make FC=gfortran
cd ..
make FC=gfortran link
Cheers, Edo |
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 6:18:01 PM PDT - Mon, Aug 20th 2012 |
|
Please post the full link step
|
Rwohlhueter,
Could you please post the full output you get when typing "make FC=gfortran link"?
Could you also check from synaptic if you have blas and/or lapack installed?
|
|
|
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 3:29:12 PM PDT - Sun, Sep 9th 2012 |
|
build from v6.1 source fails at libpeigs
|
Trying to build NWChem-src-2012-Jul-25 on an AMD64 Linux machine running
Ubuntu 12.04. Using these envars, running as root: NWCHEM_TARGET=LINUX64,
NWCHEM_MODULES=all, and the make command `make FC=gfortran > & make.log`.
The prior 'config' seemed to work without errors.
The tail of the make.log file is copied below. Just what execvp is doing, and why there should be a "permission denied" error (I'm building as root) is unclear to me. In anycase, executable 'depend.x' is built, but not 'nwchem' or 'parallel'.
A related issue is as follows: the binary build of ecce-v6.1 in fact contains the "3rd_party" nwchem app -- which runs fine on this computer. But with one problem: that build doesn't contain the 'parallel' executable file which allows me to exploit tcgmsg to use all four processors. Curiously, the 'parallel' file, which I built on this computer from source for nwchem_v6.0, appears to do the job when I use it to invoke the nwchem binary distributed with ecce-v6.1. Are there any reasons why this hybrid work-around might have pitfalls which I haven't discovered yet?
- tail of make.log**lines 3509 to 3531**********************
ar: creating /usr/local/lib/NWChem/nwchem-6.1/lib/LINUX_64/libpeigs.a
make[3]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/src/c'
(cd ./src/f77; make)
make[3]: Entering directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/src/f77'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/src/f77'
(cd ./comm; make)
make[3]: Entering directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/comm'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/comm'
(cd ./ctof; make)
make[3]: Entering directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/ctof'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs/ctof'
rm -f libpeigs.a
ar r /usr/local/lib/NWChem/nwchem-6.1/lib/LINUX_64/libpeigs.a comm/*.o ctof/*.o src/c/*.o src/f77/*.o
/usr/local/lib/NWChem/nwchem-6.1/lib/LINUX_64/libpeigs.a
make[2]: execvp: /usr/local/lib/NWChem/nwchem-6.1/lib/LINUX_64/libpeigs.a: Permission denied
make[2]: *** [lib] Error 127
make[2]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs'
make[1]: *** [peigs_stamp] Error 1
make[1]: Leaving directory `/usr/local/lib/NWChem/nwchem-6.1/src/peigs'
make: *** [libraries] Error 1
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 9:15:32 AM PDT - Mon, Sep 10th 2012 |
|
value of NWCHEM_TARGET
|
Bob W,
what value did you assign to NWCHEM_TARGET?
I can deduct from the make log that you are using LINUX_64.
LINUX_64 is not a recognized value. LINUX64 is (you need to drop the underline).
Edo
|
|
|
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 10:38:55 AM PDT - Sat, Sep 29th 2012 |
|
Edo,
First, I apologize fro my redundant posting. My thinking was that, with the pre-compiled version of NWChem bundled with ECCE6.4, my compilation problems became moot, but qualitatively differenct problem has arisen.
But the plot is thicker. I took your keen advice that I had apparently used the invalid envar LINUX_64 (then denied it in my posting! My fingers don't always follow my eye's instructions.) When I recompiled with the right envar, I got back to my original error: "undefined reference to `_gfortran_copy_string'"
That problem I've gotten the upper hand on. Scouting around with the `nm` command, I find that indeed that the libgfortran.so.3 (as supplied by gfortran v4.6.3 - the latest synaptic offers) does not contain that symbol, but the libgfortran.so.1 supplied with the pre-compiled version of ECCE6.4 does. Linking with that library, I am able to compile the NWChem source ( NWChem-src-2012-Jul-25)
My compilation works in single cpu mode (as tested with a couple of your "examples".) But I'm not out of the woods. My build also produced the `parallel.x` executable. With the self-built version 6.0 of NWChem, I am able to exploit the 4 cpus on my computer, using the command `parallel nwchem <command-file>` (and appropritate ~/pdir/nwchem.p file), with nearly 4 times better speed. Now when I try the analogous command with version 6.1 nwchem and parallel.x, I get the following messaging error:
AUTHORS & CONTRIBUTORS
----------------------
E. J. Bylaska, W. A. de Jong, N. Govind, K. Kowalski, T. P. Straatsma,
M. Valiev, H. J. J. van Dam, D. Wang, E. Apra, T. L. Windus, J. Hammond,
J. Autschbach, F. Aquino, J. Mullin, P. Nichols, S. Hirata, M. T. Hackler,
Y. Zhao, P.-D. Fan, R. J. Harrison, M. Dupuis, D. M. A. Smith, K. Glaesemann,
sock=0, pid=1, nsent=-1, len=56
1: snd_remote: writing message to socket 399999999 (0x17d783ff).
1: snd_remote: writing message to socket 399999999 (0x17d783ff).
system error message: Bad file descriptor
sock=0, pid=2, nsent=-1, len=56
3: SemWait: error from semop -1 (0xffffffffffffffff).
3: SemWait: error from semop -1 (0xffffffffffffffff).
system error message: Invalid argument
2: snd_remote: writing message to socket 399999999 (0x17d783ff).
2: snd_remote: writing message to socket 399999999 (0x17d783ff).
system error message: Bad file descriptor
^C 4: interrupt(1)
Last System Error Message from Task 0:: Numerical result out of range
WaitAll: Child (31813) finished, status=0xd (killed by signal 13).
So again I'm stuck, and need your advice.
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 3:04:07 PM PDT - Mon, Oct 1st 2012 |
|
Bob,
I have tried to reproduce your problem, but my runs went fine.
A few things I would like you to keep in mind
1) The NWChem-src-2012-Jul-25 tarball is a development version.
The last released version is the 6.1.1 that you can find at
http://www.nwchem-sw.org/images/Nwchem-6.1.1-src.2012-06-27.tar.gz
2) We strongly recommend compiling NWChem with MPI (there are only a few
extra environment variables to set)
3) Have you tried to run in parallel using two processes instead of four?
Cheers, Edo
|
|
|
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 12:47:08 PM PDT - Thu, Oct 4th 2012 |
|
The good news is that the flaw in the parallel version is not fatal. That is, I've carefully compared the outputs of an example run (the md/ache set) comparing the nwchem version bundled with ecce (1 processor) to my compilaton (1 processor, no error reports) to my compilation using 4 processors. The results, within round-off errors, are identical.
The symptom is that all four processors are active, then three drop out, while the remaining one carries on at 100% until I stop with ctrl-C.
The bad news is that I re-compiled (apparently successfully) for mpi (openmpi in on my system). But I get mpi messaging errors when I try to run it. For eample,
bobw@winter-linux: ~...md/ache_6_mpi [216]> mpirun -np 4 $NWCHEM_TOP/bin/LINUX64/nwchem mache.nw
mpirun -np 4 /usr/local/lib/NWChem/nwchem-6.1-mpi/bin/LINUX64/nwchem mache.nw
argument 1 = mache.nw
0:Segmentation Violation error, status=: 11
1:Segmentation Violation error, status=: 11
(rank:1 hostname:winter-linux pid:28340):ARMCI DASSERT fail. ../../ga-5-1/armci/src/common/signaltrap.c:SigSegvHandler():310 cond:0
2:Segmentation Violation error, status=: 11
(rank:2 hostname:winter-linux pid:28341):ARMCI DASSERT fail. ../../ga-5-1/armci/src/common/signaltrap.c:SigSegvHandler():310 cond:0
3:Segmentation Violation error, status=: 11
(rank:3 hostname:winter-linux pid:28342):ARMCI DASSERT fail. ../../ga-5-1/armci/src/common/signaltrap.c:SigSegvHandler():310 cond:0
Last System Error Message from Task 1:: No such file or directory
Last System Error Message from Task 2:: No such file or directory
Last System Error Message from Task 3:: No such file or directory
MPI_ABORT was invoked on rank 3 in communicator MPI COMMUNICATOR 4 DUP FROM 0
with errorcode 11.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
64/nwchem mache.nw
.
.
.
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 2:26:49 PM PDT - Thu, Oct 4th 2012 |
|
Bob,
What happens when run the MPI binary using a single processor?
Edo
|
|
|
|
|
|
Clicked A Few Times
Threads 2
Posts 7
|
|
| 1:34:58 PM PDT - Mon, Oct 8th 2012 |
|
Qualitatively similar: see output bleow.
I suspect it has more to do with my openmpi setup that with nwchem. I first installed openmpi (via synaptic) just fot the purpose of running the mpi version of nwchem. I've not used in in any other context, and wonder if there is some staightforward way to test it. (I'll check out the openmpi website.)
by the way, in the meantime, I have the tcgmsg version running correctly (I wish I could tell you precisely how!) So I'm bot really hurting. But since you recommended the mpi version, it's become a challenge in its own right.
>>>>>>>>>>>>>>>>>>one processor output >>>>>>>>>>>>>>>>>>>>>>>>>>
bobw@winter-linux: ~...md/ache_7_mpi_1proc [132]> mpirun -np 1 nwchem_6.1_mpi mache.nw | tee mache.stdout
mpirun -np 1 nwchem_6.1_mpi mache.nw
tee mache.stdout
argument 1 = mache.nwbobw@winter-linux: ~...md/ache_7_mpi_1proc [132]> mpirun -np 1 nwchem_6.1_mpi mache.nw | tee mache.stdout
mpirun -np 1 nwchem_6.1_mpi mache.nw
tee mache.stdout
argument 1 = mache.nw
0:Segmentation Violation error, status=: 11
(rank:0 hostname:winter-linux pid:5936):ARMCI DASSERT fail. ../../ga-5-1/armci/src/common/signaltrap.c:SigSegvHandler():310 cond:0
Last System Error Message from Task 0:: No such file or directory
MPI_ABORT was invoked on rank 0 in communicator MPI COMMUNICATOR 4 DUP FROM 0
with errorcode 11.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
bobw@winter-linux: ~...md/ache_7_mpi_1proc
mpirun has exited due to process rank 0 with PID 5936 on
node winter-linux exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
|
|
Edited On 1:39:15 PM PDT - Mon, Oct 8th 2012 by Rwohlhueter
|
|
|
|
|
|
Just Got Here
Threads 0
Posts 1
|
|
| 2:42:46 PM PST - Thu, Nov 15th 2012 |
|
linking with libgfortran.so.3 and libgfortran.so.1
|
Hi,
I'm trying to c_ompile the Nov 6 2012 version of nwchem with openmpi. I will be running on one machine - a quad core i7, so I want to be able to use the 4 cores in parallel. It's running Suse 11.
I'm running into the problem that Rwohlhueter also observed: link fails with the following error:
/usr/local/nwchem-src-2012-11-06/src/tools/install/lib/libga.a(ilaenv.o): In function `gal_ilaenv_':
ilaenv.f:(.text+0x71): undefined reference to `_gfortran_copy_string'
Earlier in this thread Rwohlhueter says "I find that indeed that the libgfortran.so.3 (as supplied by gfortran v4.6.3 - the latest synaptic offers) does not contain that symbol, but the libgfortran.so.1 supplied with the pre-c_ompiled version of ECCE6.4 does. Linking with that library, I am able to c_ompile the NWChem source ( NWChem-src-2012-Jul-25)"
I've tried to link using libgfortran.so.1 instead of libgfortran.so.3, by changing the symbolic link for version 3 to the library for version 1, but I get many link errors, as openmpi needs some routines that are in version 3 and not in 1. How do I tell the linker to use both libgfortran.so.1 and libgfortran.so.3? Is there something I change in the make file?
Thanks!
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 7
Posts 1300
|
|
| 10:24:12 AM PST - Fri, Nov 16th 2012 |
|
Rbmetz,
Could you please send me the output of
1) printenv LD_LIBRARY_PATH
2) ldd nwchem
where nwchem is the one you got from Ecce6.4
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC
| |
