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):
- Installed cygwin from http://www.cygwin.com/ by downloading and running setup.exe.
In the setup, I chose to install everything.
- 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.
- 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.)
- 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.)
- 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.
- 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.)
- 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.)
- To run oof2 in text mode:
prompt> oof2 --text
- 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