OOF2 on Cygwin

Steps I took to build OOF2 (2.0.1) on Cygwin (My Machine - a Toshiba Satellite running
MS Windows XP Home Edition, Version 2002, Service Pack 2.
With Cygwin DLL 1.5.21-1, GCC 3.4.4):
  1. Installed cygwin from http://www.cygwin.com/ by downloading and running setup.exe. In the setup, I chose to install everything.
  2. Installed swig1.1-883, following most of the instructions from the website: http://www.creatis.insa-lyon.fr/~bellet/creatis/cygwin/. The instructions include removing the newer version of swig, unpacking swig1.1, and installing a patch.
  3. Searched the web for the files cygdpstk-1.dll and cygdps-1.dll (missing by default in cygwin) and put these in /usr/X11R6/bin. These files were obtained using a link on the website: http://comments.gmane.org/gmane.os.cygwin.xfree/16493. (I found out about these required dll's after I already built oof2 and ran it on cygwin. It gave a very cryptic error message that said "No such file or directory" associated with loading oofimagecmodule.dll. After a lot of tests, it dawned on me that that the python module itself wasn't missing, but that some of the dll's that it linked to were. I used cygcheck (which works like ldd) on oofimagecmodule.dll to show what other dll's it depends on.)
  4. Made a small change in oof2setuputils.py, passing in the argument string "pkg-config.exe" instead of "pkg-config" in check_exec, which is called by the method pkg_check. (The command "whereis pkg-config" would reveal "pkg-config.exe" as the full name of the executable under cygwin.)
  5. Made some changes to SRC/image/DIR.py: def set_clib_flags(c_lib): import oof2setuputils if oof2setuputils.check_exec('Magick++-config'): oof2setuputils.add_third_party_includes('Magick++-config --cppflags', c_lib) #oof2setuputils.add_third_party_libs('Magick++-config --ldflags --libs', # c_lib) #RCL: oof2setuputils.add_third_party_libs('Magick++-config --ldflags',c_lib) magicklibs='Magick++ Wand Magick jbig lcms tiff freetype jasper jpeg png fpx Xext Xt SM ICE X11 bz2 xml2 z gdi32 pthread m pthread' for ml in string.split(magicklibs,' '): c_lib.externalLibs.append(ml) else: print "Can't find Magick++-config! Your ImageMagick installation may be defective." c_lib.externalLibs.append('oof2common') Note that I took the output of "Magick++config --libs" on my system (-lMagick++ -lWand -lMagick -ljbig -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng -lfpx -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lgdi32 -lpthread -lm -lpthread), removed -ldpstk and -ldps because cygwin can't find them, and put the modified output (after taking out the leading "-l") in the string magicklibs. Although cygdps-1.dll and cygdpstk-1.dll may be present, I do not have libdps.a and libdpstk.a on my system.
  6. Invoked the build/install command: prompt> python setup.py build --library-dirs=/bin --libraries=python2.4 --blas-libraries="blas lapack m" install --prefix=/HOME/RHON (The --blas-libraries option may not be necessary in newer versions of setup.py.)
  7. Set PATH and PYTHONPATH (command line or .bashrc) export PATH=/HOME/RHON/lib:/HOME/RHON/bin:.:$PATH export PYTHONPATH=/HOME/RHON/lib/python2.4/site-packages (Setting LD_LIBRARY_PATH did not work, so I put the path /HOME/RHON/lib into PATH.)
  8. To run oof2 in text mode: prompt> oof2 --text
  9. To run oof2 in graphics mode, start X and invoke: prompt> DISPLAY=:0.0 oof2 or enter "startx" at the prompt, then run oof2 on the X terminal.

Status (10/05/06) An error similar to the lock error mentioned below is documented here: http://www.cygwin.com/ml/cygwin/2005-07/msg01378.html The sample program from this site also returns an error on my cygwin system. An error also shows up when I run /usr/lib/python2.4/test/regrtest.py (10/04/06) Found a better solution to the pango/get_metrics problem on cygwin. Instead of "None", fontcontext.get_language() is passed as argument to get_metrics(). This seems to work just fine in sancho (as well as fixing the bug on cygwin). But if it gives problems on other platforms, I may check for sys.platform before making this change. One caveat: On sancho, font.get_metrics(None).get_approximate_char_width() gives a value of 9125, while font.get_metrics(fontcontext.get_language()).get_approximate_char_width() returns a value of 6505. The GUI looks just fine in either case. (10/04/06) Got oof2 to run in graphics mode: The Pango-ERROR is still there, and it occurs in gtkutils.py on the line that calls get_metrics(None). As a temporary workaround to this bug, I put hard-coded values as such: def widgetFontSizes(widget): fontdesc = widget.get_style().font_desc fontcontext = widget.create_pango_context() font = fontcontext.load_font(fontdesc) #RCL: #fontmetrics = font.get_metrics(None) #return (fontmetrics.get_approximate_char_width()/pango.SCALE, # fontmetrics.get_approximate_digit_width()/pango.SCALE) return (9000/pango.SCALE, 8000/pango.SCALE) Another glaring bug shows up when one tries to view a microstructure by opening the graphics window. An "error: can't allocate lock" occurs. On the terminal, it says "sem_init: Resource temporarily unavailable." This bug does not show up when oof2 runs with --unthreaded. The traceback is as follows: File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/worker.py", line 180, in run self.menuitem.callback(self, *self.args, **self.kwargs) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/mainmenu.py", line 357, in openGfx window = gfxManager.openWindow() File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/gfxmanager.py", line 43, in openWindow w = self._newWindow(name, count, **kwargs) # opens real or ghost gfx window File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/GUI/gfxwindow.py", line 1557, in _newWindow return GfxWindow(name, count, self, **kwargs) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/GUI/gfxwindow.py", line 81, in __init__ gfxmanager, clone=clone) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/ghostgfxwindow.py", line 557, in __init__ map(self.newToolboxClass, toolbox.toolboxClasses) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/ghostgfxwindow.py", line 1184, in newToolboxClass tb.makeMenu(menu) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/genericselecttoolbox.py", line 90, in makeMenu self.rebuildMenus() File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/genericselecttoolbox.py", line 116, in rebuildMenus discussion=""" File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/GUI/gfxmenu.py", line 234, in _newAddItem return mainthread.runBlock(self.addItem_thread, (item,)) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/GUI/mainthreadGUI.py", line 42, in runBlock_gui return oof_mainiteration.oof_idle_block_add(func, args, kwargs) File "/HOME/RHON/lib/python2.4/site-packages/oof2/common/IO/GUI/oof_mainiteration.py", line 117, in oof_idle_block_add callbackobj.event.wait() File "/tmp/python.340/usr/lib/python2.4/threading.py", line 348, in wait self.__cond.wait(timeout) File "/tmp/python.340/usr/lib/python2.4/threading.py", line 197, in wait waiter = _allocate_lock() (10/03/06) Was able to run all the regression tests successfully on cygwin, with the exception of this line in TEST/microstructure_test.py which causes the test to abort (core dump): self.assertRaises( oofimage.ImageMagickError, OOF.Microstructure.Create_From_ImageFile, filename="nosuchfile", microstructure_name="nosuchfile", height=automatic, width=automatic) (The program crashes in the call to "image.read(filename)" in the OOFImage constructor, and does not even reach the subsequent "catch" clause.) If I comment this out in microstructure_test.py, everything works fine. (mesh_test.py and solver_test.py each froze once while testing though, but they worked fine at other times.) (10/02/06) Found a fix to the first problem mentioned below. In the file SRC/engine/solver.h, I made the following changes: class LinearSolver { public: /* pointer to correct preconditioner will not be set at construction of solver. Will be constructed through a UI */ std::string _message; std::vector rowblocks, colblocks; LinearSolver() { // For some reason, giving an initial value to // _message prevents OOF2 from crashing on cygwin // when _message is assigned a non-empty string, // for instance inside solve(...). _message="OOF"; } ... } That OOF2 aborts without setting an initial value for _message does not make sense though. This is probably a bug in cygwin. (09/28/06) oof2 can start up in text mode, but if I run this script that solves a simple plane elasticity problem, it aborts and core dumps. If I omit the Solver.Solve step, it does not abort and works fine. oof2 can't start up in normal graphics mode. I get an error after invoking "DISPLAY=:0.0 oof2": Pango-ERROR **: file /instsoft/libxml/pango-1.8.1/pango/break.c: line 780 (pango_default_break): assertion failed: (IN_BREAK_TABLE (break_type)) aborting...

RCL
Last modified: Thu Sep 28 14:33:06 EDT 2006