compile problems - src/nmodl/parse1.y

Post Reply
evan

compile problems - src/nmodl/parse1.y

Post by evan »

I'm trying to compile neuron 7.0 on what appears to be a redhat 7.3 cluster. The build craps out at the following compile step:

make[3]: Entering directory `/home/evan/nrn-7.0/src/nmodl'
[cut]
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../src/oc -I../../src/oc -I../../src/oc -I../../src/parallel -I../../src/nrnjava -I../../src/nrncvode -I../../src/ivos -I../../src/sundials -I../../src/nrnpython -I../../src/src/modlunit -DNMODL=1 -DNOCMODL=1 -DCVODE=1 -DVECTORIZE=1 -g -O2 -MT parse1.o -MD -MP -MF ".deps/parse1.Tpo" -c -o parse1.o parse1.c; \
then mv -f ".deps/parse1.Tpo" ".deps/parse1.Po"; else rm -f ".deps/parse1.Tpo"; exit 1; fi
parse1.y: In function `yyparse':
parse1.y:406: parse error before `int'
parse1.y:408: `a2' undeclared (first use in this function)
parse1.y:408: (Each undeclared identifier is reported only once
parse1.y:408: for each function it appears in.)
make[3]: *** [parse1.o] Error 1
make[3]: Leaving directory `/home/evan/nrn-7.0/src/nmodl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/evan/nrn-7.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/evan/nrn-7.0'
make: *** [all] Error 2

The following may be helpful:

[evan@alfred nrn-7.0]$ uname -a
Linux alfred 2.4.18-26.7.xsmp #1 SMP Mon Feb 24 09:37:16 EST 2003 i686 unknown
[evan@alfred nrn-7.0]$ yacc -V
bison (GNU Bison) 1.875c
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[evan@alfred nrn-7.0]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

TIA,
Evan
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

Occasionally a statement gets into the code that works on todays compilers but not
yesterdays. The problem you see and several others was fixed at
http://www.neuron.yale.edu/hg/neuron/nr ... 87332b34c3
Anything after that should compile on your cluster.
I recommend the latest tar.gz version at
http://www.neuron.yale.edu/ftp/neuron/versions/alpha/
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

I compiled 7.1-alpha with configure
CC=gcc ./configure --prefix=$HOME/neuron --without-iv

It compiles fine, but segfaults:

[evan@alfred evan]$ ./neuron/i686/bin/nrniv
NEURON -- VERSION 7.1 (315:dbb6f14221c5) 2009-06-08
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2008
See http://www.neuron.yale.edu/credits.html

Assertion failed: file symbol.c, line 239
Segmentation fault


By the way if I use the configure option --with-mpi it picks up icc (the intel compiler) and that is just a disaster. Is there are way to focrce it to use gcc. I don't know which mpi library they have on this cluster (it's an old IBM cluster if that helps).

thanks again,
Evan.
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

Assertion failed: file symbol.c, line 239
I've seen this problem before.
Configure determined that your machine declares posix_memalign but in fact
it apparently does not actually work on your machine.
It is useful for thread performance since it helps avoid cachline sharing
but it is not needed in your cluster environment.

Edit the nrnconf.h file and force
#define HAVE_POSIX_MEMALIGN 1
to
/* #undef HAVE_POSIX_MEMALIGN */
or else edit src/oc/symbol.c and change the line
#define HAVE_MEMALIGN 1
to
#define HAVE_MEMALIGN 0
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

By the way if I use the configure option --with-mpi it picks up icc (the intel compiler) and that is just a disaster.
This problem must be worked around to run a parallel mpi program. (And for full functionality use --with-paranrn instead
of --with-mpi.) Since mpicc wraps the icc compiler your choices are to set CC and CXX so they get the intel compiler,
or else to build another version of mpi using gcc. If you choose the latter course, I recommend mpich2.
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

Undefining HAVE_POSIX_MEMALIGN fixed the segfault.

I'm still having problems compiling the parallel version. All the versions of mpicc that I can find on this machine use icc. This is the configure invocation that I am using:

Code: Select all

CC=icc CXX=icc ./configure --prefix=$HOME/neuron --without-iv --with-paranrn
icc produces many warnings which mostly seem to be the following:
word.c(276): warning #266: function declared implicitly
return (ldelete(size, TRUE));
^

word.c(284): warning #880: omission of explicit type is nonstandard ("int" assumed)
delbword(f, n)
^

word.c(284): warning #1193: standard requires that parameter "f" be given a type by a subsequent declaration ("int" assumed)
delbword(f, n)

I assume these warnings are not important.

Eventually the build craps out with:
/bin/sh ../../libtool --tag=CC --mode=link mpicc -g -o libmemacs.la -rpath /home/evan/neuron/i686/lib ansi.lo basic.lo bind.lo buffer.lo display.lo file.lo fileio.lo line.lo lock.lo main1.lo random.lo region.lo search.lo spawn.lo tcap.lo termio.lo window.lo word.lo -lncurses -lm -ldl
icc -shared .libs/ansi.o .libs/basic.o .libs/bind.o .libs/buffer.o .libs/display.o .libs/file.o .libs/fileio.o .libs/line.o .libs/lock.o .libs/main1.o .libs/random.o .libs/region.o .libs/search.o .libs/spawn.o .libs/tcap.o .libs/termio.o .libs/window.o .libs/word.o -lncurses -lm -ldl -lc -Wl,-soname -Wl,libmemacs.so.0 -o .libs/libmemacs.so.0.0.0
ld: .libs/libmemacs.so.0.0.0: undefined versioned symbol name __register_frame_info@@GLIBC_2.0
ld: failed to set dynamic section sizes: Bad value
make[3]: *** [libmemacs.la] Error 1

It seems to be looking for glibc.

thanks again,
Evan.
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

the warnings are due to old K&R c and can be ignored.
Did you start from a clean set of sources?
The only thing I can think of is to install icc on my machine and see if I have any problems building.
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

I tried again from clean source. The compiler is quite old:

[evan@alfred nrn-7.1]$ icc -V
Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build 20030307Z
Copyright (C) 1985-2003 Intel Corporation. All rights reserved.

GNU ld version 2.11.93.0.2 20020207
Supported emulations:
elf_i386
i386linux
elf_i386_glibc21

I could try building my own private gcc/mpich2 tool chain, but I'm a bit over those sorts of activities. I might see if there is another machine I can use.
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

the latest intel compiler refused to install on my machine. In your case, if no other machine is available, I guess I'd install a recent gcc and mpich2 and go
on from there.
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

I built my own version of mpich2 and was able to compile the parallel version of neuron against that.

thanks,
Evan.
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

The parallel version of neuron segfaults when trying to run the Traub cortex model (model # 45539).

Thanks again.

[evan@alfred nrntraub]$ nrniv init.hoc
NEURON -- VERSION 7.1 (315:dbb6f14221c5) 2009-06-08
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2008
See http://www.neuron.yale.edu/credits.html

loading membrane mechanisms from i686/.libs/libnrnmech.so
Additional mechanisms from files
mod/alphasyndiffeq.mod mod/alphasynkin.mod mod/alphasynkint.mod mod/ampa.mod mo d/ar.mod mod/cad.mod mod/cal.mod mod/cat.mod mod/cat_a.mod mod/gabaa.mod mod/gga p.mod mod/iclamp_const.mod mod/k2.mod mod/ka.mod mod/ka_ib.mod mod/kahp.mod mod/ kahp_deeppyr.mod mod/kahp_slower.mod mod/kc.mod mod/kc_fast.mod mod/kdr.mod mod/ kdr_fs.mod mod/km.mod mod/naf.mod mod/naf2.mod mod/naf_tcr.mod mod/nap.mod mod/n apf.mod mod/napf_spinstell.mod mod/napf_tcr.mod mod/par_ggap.mod mod/pulsesyn.mo d mod/rampsyn.mod mod/rand.mod mod/ri.mod mod/traub_nmda.mod
made it to end of network_specification_interface.hoc
Initializing Network
creating 3560 cells:

creating 1000 suppyrRS cells
creating 50 suppyrFRB cells
creating 90 supbask cells
creating 90 supaxax cells
creating 90 supLTS cells
creating 240 spinstell cells
creating 800 tuftIB cells
creating 200 tuftRS cells
creating 500 nontuftRS cells
creating 100 deepbask cells
creating 100 deepaxax cells
creating 100 deepLTS cells
creating 100 TCR cells
creating 100 nRT cells
Done creating cells
Constructing suppyrRS_to_suppyrRS maps
Constructing suppyrRS_to_suppyrFRB maps.. and so forth
constructing suppyrRS_to_nontuftRS
constructing suppyrFRB_to_suppyrRS
finished construction of cell connection tables
Starting construction of compartment map connection tables
calling com_suppyrRS_to_suppyrRS = synaptic_compmap_construct
...
com_TCR_to_tuftRS
Construct gap-junction tables
Adding constant random current injections to the somas
of some cell types.
Completed adding constant random current injections.
Total number: syn_num = 50000 suppyrRS_to_suppyrRS synapses
creating 1000 NetStim's for suppyrRS cells
creating 50 NetStim's for suppyrFRB cells
creating 800 NetStim's for tuftIB cells
creating 200 NetStim's for tuftRS cells
creating 500 NetStim's for nontuftRS cells
creating 100 NetStim's for TCR cells
at end
before setting traub exact connection coefficients, setuptime = 105
nrniv: Segmentation violation
in init.hoc near line 47
^
scale_connection_coef(0.5, 0.998829)
traubexact_coef(suppyrRS[0], Matrix[287], Vector[147])
pcitr()
pcitr(..., ...)
and others
hines
Site Admin
Posts: 1600
Joined: Wed May 18, 2005 3:32 pm

Re: compile problems - src/nmodl/parse1.y

Post by hines »

This model is too large to run on my desktop. But try changing init.hoc so that
use_traubexact = 0
and see if the problem goes away.
Also try
nrngui mosinit.hoc
and see if the problem depends on whether "Exact traub style ri" is checked.

I've worked extensively with this model on large scale clusters but use a version that
has a lot of changes with regard to parallelization. If you wish to use this model
on a cluster it is probably best to get my version (I can send it via email, just write to
michael dot hines at yale dot edu)
evan

Re: compile problems - src/nmodl/parse1.y

Post by evan »

The segfault went away when use_traubexact = 0. Now I get nrn_timeout, using 10 nodes. I have no idea how (or if) the code is distributing the workload over the processors. I'll try Michael Hines' optimized code.

Evan.
Post Reply