The following content no longer applies to current Micro-Manager source code.
Contributed by Nicos Pavlov, 9/26/2010
I would like to share here some of the problems we had to face for compiling Micromanager on Unix based on Kubuntu. I could not find anything related in the forum, and hope that it could help some people facing the same problems, or help making some upstream patches.
For the context, we needed a Unix version of Micromanager to enable support of Firewire cameras. The packages provided according to http://www.endrov.net/index.php?title=Installing_Micromanager_on_Linux are great, but were not compiled with libdc1394, so that we had to compile it ourselves. The issues discussed here are based no the howto given in http://valelab.ucsf.edu/~nico/MMwiki/index.php/Linux_installation_from_source_%28Ubuntu%29. The compilation was made with libdc1394 2.0.1 manually installed, as the one given in distributions is newer and seemed to have problems for linking.
According to this howto, the compilation went fine, but we had several issues to get 1394 support to work. Those problems could be reproduced in Kubuntu karmic (9.10) and lucid (10.04). The problems seem essentially to be discrepancies between *nix distributions and Mac systems, where most of the code is developed to my understanding.
1. It seems that dynamic linking to libraries has some problems. We had therefore to ensure that static libraries were preferred to dynamic ones. For this we applied the following patch to $(SRCDIR)/configure.common: Index: configure.common
=================================================================== — configure.common (revision 5359) +++ configure.common (working copy) @@ -67,8 +67,8 @@
LPTHREAD="-lpthread"
DEVICEADAPTERPATH="/usr/lib/micro-manager"
JARPATH="/usr/share/java"
- LIBEXTA=”so” - LIBEXTB=”a” + #LIBEXTA=”so” + #LIBEXTB=”a”
;;
esac AC_MSG_RESULT($LPTHREAD)
This gives the same behaviour as in Mac system, as I could understand it, as compilation in Snow Leopard selects static libraries.
2. We had to ensure that libusb-1.0 was installed, as we had errors in linking to this library. This problems was also reported in the forum in http://micro-manager.3463995.n2.nabble.com/dc1394-Adapter-Issues-on-Ubuntu-td5271915.html#a5271915. I think this dependency should be made clear either in the howto for compilation or on the page about the libdc1394 module, or during configuration stage. Not having it just provides linking problems at launching, without any warning during compiling the package, which can lead to issues in understanding the source of the problem.
3. This point is probably related to the distribution, but we still had problems with libusb even after installation, where it seems that the distributed libdc1394 on Kubuntu does no link to libusb. We had to install the libdc1394 manually to get it to work (version 2.0.1 was used).
4. There seem to be a hidden dependency in the case of Unix with libdc1394 which links to libraw1394 to work. This implies that libraw1394 must be installed before compiling libdc1394; we installed version 1.2.0, which works well with libdc1394 2.0.1. Moreover, micromanager must also link to this library to avoid linking problems. We therefore had to patch $(SRCDIR)/DeviceAdapters/configure.in to detect this library Index: configure.in
=================================================================== — configure.in (revision 5359) +++ configure.in (working copy) @@ -80,6 +80,31 @@ AC_SUBST(LIBDC1394) AM_CONDITIONAL([BUILD_DC1394], [test -f “$LIBDC1394”])
+AC_MSG_CHECKING(for libraw1394) +AC_FIND_FILE([libraw1394], [/usr/include /usr/local/$ARCH/include], RAW1394INCDIR) +if test x$RAW1394INCDIR = xNO; then + AC_MSG_RESULT([not found]) +else + AC_CHECK_HEADERS([$RAW1394INCDIR/libraw1394/raw1394.h]) + if test -z “$LIBRAW1394”; then + AC_FIND_FILE([libraw1394.$LIBEXTA], [/usr/lib /usr/lib64 /usr/local/$ARCH/lib], RAW1394LIBDIR) + if test x$DC1394LIBDIR = xNO; then + AC_FIND_FILE([“libraw1394.$LIBEXTB”], [/usr/lib /usr/lib64 /usr/local/$ARCH/lib], RAW1394LIBDIR) + if test x$RAW1394LIBDIR = xNO; then + AC_MSG_RESULT([“libraw1394 not found”]) + else + AC_MSG_RESULT([“libraw1394.$LIBEXTB found”]) + LIBRAW1394=”$DC1394RAWDIR/libraw1394.$LIBEXTB” + fi + else + AC_MSG_RESULT([“libraw1394.$LIBEXTA” found]) + LIBRAW1394=”$RAW1394LIBDIR/libraw1394.$LIBEXTA” + fi + fi +fi +AC_SUBST(LIBRAW1394) +
- and for National Instrumenst boards
AC_MSG_CHECKING(for NIDaQ) AM_CONDITIONAL([BUILD_NIDAQ],[test -f “../../3rdParty/trunk/NationalInstruments/NI-DAQmxBase/includes/NIDAQmxBase.h”])
and to patch $(SRCDIR)/DeviceAdapters/dc1394/Makefile.am for linking: Index: Makefile.am =================================================================== — Makefile.am (revision 5359) +++ Makefile.am (working copy) @@ -3,7 +3,7 @@ libmmgr_dal_dc1394_la_SOURCES = dc1394.cpp dc1394.h
-
- adding the libtool library gives problems on Intel OS X 10.4, adding the
static lib works
-
- TODO: find the library in configure
-libmmgr_dal_dc1394_la_LIBADD = ../../MMDevice/.libs/libMMDevice.a $(LIBDC1394) +libmmgr_dal_dc1394_la_LIBADD = ../../MMDevice/.libs/libMMDevice.a $(LIBDC1394) $(LIBRAW1394) libmmgr_dal_dc1394_la_LDFLAGS = -module
install:
By comparison with a Mac system, the compilation indeed does not seem to need the library libraw1394. I assume that the low level libraries are different. However, this seems to be rather general, as this dependency is announced by libdc1394 as standard.
Those steps provided a working micromanager with Firewire support, which could be tested with a IIDC 1394 camera from Basler manufacturer.
5. Finally, on a general point of view, I think it is a shame that Firewire is not supported on Windows. I know it is easy to say things like that without doing them, but there is a free driver for 1394 support on Windows (CMU 1394 driver, http://www.cs.cmu.edu/~iwan/1394/), which is employed by several programs and reported to be quite stable. As libdc1394 seems to have some issues to be ported on Windows, it would be great if a module of micromanager could be developed with this driver. I unfortunately do not have the time to do it myself presently.