It was Sun's own version of make (which doesn't even provide version information as far as I can see...).
Doing the substitutions in the Makefile did make a difference, the files in nrnoc are now compiled but libnrnoc itself could still not be linked.
I then tried GNU make (on a fresh source, just to make sure) and it yields the same result
Code: Select all
bash-2.05$ /opt/sfw/bin/gmake -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for sparc-sun-solaris2.9
Code: Select all
source='ocnoiv.c' object='ocnoiv.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
mpcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I. -I../../src/oc -I../../src/o
c -I../../src/oc -I../../src/parallel -I../../src/nrnjava -I../../src/nrncvode -I../.
./src/ivos -I../../src/sundials -I../../src/nrnpython -I../../src/oc -I../../src/oc -
I../../src/scopmath -I../../src/sparse13 -DCABLE=1 -DOOP=1 -D_REENTRANT -lmpi -c oc
noiv.c
...
(warnings here)
...
source='cprop.c' object='cprop.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
mpcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I. -I../../src/oc -I../../src/o
c -I../../src/oc -I../../src/parallel -I../../src/nrnjava -I../../src/nrncvode -I../.
./src/ivos -I../../src/sundials -I../../src/nrnpython -I../../src/oc -I../../src/oc -
I../../src/scopmath -I../../src/sparse13 -DCABLE=1 -DOOP=1 -D_REENTRANT -lmpi -c cp
rop.c
"cprop.c", line 17: warning: implicit function declaration: hoc_malchk
/bin/bash ../../libtool --tag=CC --mode=link mpcc -D_REENTRANT -lmpi -o nrnoc ocm
ain.o nrnnoiv.o ocnoiv.o cprop.o ../oc/modlreg.o libnrnoc.la ../oc/liboc.la ../scopma
th/libscopmath.la ../sparse13/libsparse13.la ../nrnmpi/libnrnmpi.la -lpthread -lm
mpcc -D_REENTRANT -o .libs/nrnoc ocmain.o nrnnoiv.o ocnoiv.o cprop.o ../oc/modlreg.o
./.libs/libnrnoc.so ../oc/.libs/liboc.so ../scopmath/.libs/libscopmath.so ../sparse1
3/.libs/libsparse13.so ../nrnmpi/.libs/libnrnmpi.so -lmpi -lpthread -lm -R/home/eper
fa/neuron/nrn/sparc/lib
Undefined first referenced
symbol in file
sched_setaffinity ./.libs/libnrnoc.so
ld: fatal: Symbol referencing errors. No output written to .libs/nrnoc
gmake[4]: *** [nrnoc] Error 1
gmake[4]: Leaving directory `/home/eperfa/neuron/nrn/src/nrnoc'
The full log can be accessed here:
http://users.itk.ppke.hu/~divad/gmake.log
I included /usr/include in my $LD_LIBRARY_PATH just to make sure it was not the cause of failure (it is where Solaris keeps sched.h) but it didn't make any difference.
After a bit of googling I found that sched_setaffinity is a function provided by the Linux kernel but not Solaris so I guess it's not something to be used in an environment like this.
Both Linux and the Solaris OS support the notion of binding a process or thread to a processor. Linux allows binding to a set of processors for non-exclusive use of those processors. The Solaris OS allows binding to a set of processors for exclusive use, (that is, CPU fencing), but does not allow binding to a group for non-exclusive use (except via Solaris Zones?). Linux does not have a mechanism for CPU fencing, though implementations can be found on the web (see, for example, the CPUSETS for Linux page on the bullopensource.org site). The Linux system calls that are processor affinity based are sched_setaffinity(2) and sched_getaffinity(2). The Solaris OS has the following:
processor_bind(2) to bind/unbind LWPs or processes to a processor
pset_create(2) to set up a processor set
pbind(1) and psrset(1), which are command-line interfaces
From:
http://developers.sun.com/solaris/artic ... x_app.html
I'm no expert in these fields but I found only one call to the sched_setaffinity function, in src/nrnoc/multicore.c, in the following function
Code: Select all
void setaffinity(int i) {
int mask;
return;
#if 0
cpu_set_t mask;
CPU_ZERO(&mask);
CPU_SET(i, &mask);
#endif
mask = (1 << i);
sched_setaffinity(0, 4, &mask);
}
The return statement in the second line, to my understanding, means that the sched_setaffinity function will never actually get called - so I temporarily removed (commented) it and tried to compile the whole thing yet again.
Code: Select all
source='Binomial.cpp' object='Binomial.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
/bin/bash ../../libtool --tag=CXX --mode=compile mpCC -DHAVE_CONFIG_H -I. -I. -I../..
-I../.. -I../.. -I../../src/nrnoc -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/ivos -mt -lmpi -c -o Binomial.lo Binom
ial.cpp
mpCC -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../src/nrnoc -I../../src/o
c -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/ivos
-mt -lmpi -c Binomial.cpp -DPIC -o .libs/Binomial.o
"./neuron_gnu_builtin.h", line 112: Error: std::abs(float) already had a body defined.
"./neuron_gnu_builtin.h", line 123: Error: std::abs(long) already had a body defined.
2 Error(s) detected.
gmake[3]: *** [Binomial.lo] Error 1
gmake[3]: Leaving directory `/home/eperfa/neuron/nrn/src/gnu'
Right now I'm way too tired to find the cause of this but I'll take another look at it tomorrow - though I'd really appreciate any ideas if you still have a few moments for this.
Thanks,
Adam