cross-compiling neuron (host: linux: target: windows)

[aschloegl]

I'm trying to cross-compile neuron 7.3.alpha (r755) with the mingw-cross-compiler environment, using debian as host platform and x86_64-w64-mingw32 as target. I came quite far, even managed to compile nrnmodl for the host and target. But now I've come across a problem resulting the following compiler error.

../oc/.libs/liboc.a(hoc.o): In function `inputReadyThread':
.../tmp-neuron/nrn-7.3/src/oc/hoc.c:970: undefined reference to `stdin_event_ready'

In order to reproduce the problem, you need to install all prerequisites of [1]. Then

Code: Select all

  git clone https://github.com/schloegl/mxe.git
  cd  mxe 
  make neuron 

It will take some time, to cross-compile all dependencies.

Has anyone an idea how to fix the problem described above ?


Alois


[1] http://mxe.cc

[hines]

My only experience with this is via cygwin and MinGW on windows 7. My notes for the various combinations are in
http://www.neuron.yale.edu/hg/neuron/nr ... howtomingw
I think most of the issues about having to build some missing libraries are mentioned.

the undefined reference when executing make in the oc library should be resolved from ocnoiv.c and thereafter from
src/ivoc/ivocwin.cpp

It will be tricky to get a full cross compiled version with the present Makefile.am since on the one hand the mod files in nrn/src/nrnoc need to be translated with nocmodl on the debian
machine and on the other hand, after installation on mswin, nocmodl needs to translate mod files from projects.

Hmm. After getting the git repository and looking quickly at src/neuron.mk I think I would avoid the
http://www.neuron.yale.edu/neuron/download/getstd
and instead start with
http://www.neuron.yale.edu/ftp/neuron/versions/alpha/
since there are very many 64 bit mswin changes.

[aschloegl]

Thanks for your reply. Yes, I've upgraded to 7.3.alpha-755, and the reported error messages is from that attempt.

I've addressed the nocmodl issue by compiling neuron twice, for the host and for the target platform, and then messing with makefile, to use the host nocmodl within the Makefile for the target. This seems to work.

The strange thing is, that ivocwin.o does not seem to define stdin_event_ready, (tested with x86_64-w64-mingw32-nm ivocwin.o |grep stdin_). Although, ivocwin.cpp contains it.

Alois

[hines]

I've cloned your mxe repository and am in the process of building. I'm very impressed with the automatic nature of the build and it is very convenient on ubuntu to install what is
needed (such as gawk) when it stops with an error and then continue on with 'make'. It hasn't yet gotten to NEURON but I hoping to gain some experience with it this weekend.
Anyway, I'm wondering if openmpi can be added to the list of packages to be installed. The reason I mention it is that my goal with the 64 bit setup.exe installer is that
mpi + enthought python + neuron + interviews works. At present, enthought's numpy and mayavi seem to assume openmpi but neuron uses mpich2. I looked on the web and it seems that a setup.exe
for openmpi is no longer available and I was a bit daunted by the prospect of building from sources under mingw. But I hope that mxe makes this reasonably straightforward.

I am a bit concerned about the Target being i686-pc-mingw32 instead of x86_64-w64-mingw32 .

In the past, when building NEURON, the 'make install' was replaced by 'make mswin' which marshalled all the necessary distribution files and then created a setup.exe using nsis.
Do you think it is conceivable to accomplish the same result (build a setup.exe) with mxe?

If all this eventually works out, it will be a great way for me to build. As you can see from the howtomingw, the build currently requires too much mothering.

[hines]

building mxe I can't get past
Failed to build package libmikmod!
------------------------------------------------------------
make[3]: *** [drv_AF.lo] Error 1

The log/libmikmod file succeeds with configure but
/bin/sh ../libtool --silent --mode=compile i686-pc-mingw32-gcc
-DHAVE_CONFIG_H -msse2 -pthread -fno-strength-reduce -funroll-loops
-ffast-math -Wall -D_REENTRANT -I../include -I.. -I../include
-DMIKMOD_H=../include/mikmod.h -c ../drivers/drv_AF.c

../libtool: 1568: ../libtool: preserve_args+= --silent: not found
../libtool: 1: eval: base_compile+= i686-pc-mingw32-gcc: not found
...

which seems like an environment problem. However, a hundred or so other packages built without error using lines like:
/bin/bash ./libtool --tag=CC --mode=compile i686-pc-mingw32-gcc ...
. I guess things are not so simple as I imagined.
(I git pulled the latest mxe version from https://github.com/mxe/mxe.git but that did not fix the problem)

[aschloegl]

I am a bit concerned about the Target being i686-pc-mingw32 instead of x86_64-w64-mingw32 .

Just add the following line to settings.mk

Code: Select all

MXE_TARGETS := i686-pc-mingw32 x86_64-w64-mingw32

and it will try to build it for both platforms.

[aschloegl]

building mxe I can't get past
Failed to build package libmikmod!
------------------------------------------------------------
make[3]: *** [drv_AF.lo] Error 1

I've fixed building libmikmod in my tree for i686-pc-mingw32. However, building libmikmod for x86_64-w64-mingw32 is currently disabled; trying to enable it results in confliction definitions of ULONG.

Is libmikmod a requirement for building neuron, or could it be disabled until a fix for libmikmod is found ?

Alois

[hines]

Yes. I see now that 'make neuron' would skip over what is not needed.

In neuron.mk you need to remove the
--without-x \
line as it defeats the --with-iv=... line. Configure knows that its target is mingw and will switch from x11 to windows.
nrniv.exe will build completely.
You'll then stop at
../../src/mswin/extra/mos2nrn.cpp:4:21: fatal error: windows.h: No such file or directory
but I believe that can be fixed by modifying src/nrniv/Makefile.am to avoid the explicit use of g++ in favor of $(CXX)

I'm a bit shakey on how to experiment with source code changes. Seems that one cannot merely go to
tmp-neuron/nrn-7.3/src/nrniv , modify the Makefile and then 'make' as the environment is incorrect. But if one
does a 'make neuron' at the top level, it will re-extract the tar.gz and the experimental changes will be lost.

I don't doubt that there will be a half-dozen or so remaining issues so why don't we correspond by email (michael dot hines at yale dot edu)
I'd like to become more familiar with this myself as it looks like it will be the simplest way to build NEURON on native windows. Also, after
a few hours of effort, I failed in building openmpi from sources on a Windows 7 guest (VirtualBox) and maybe mxe will make it.