On 2010-12-27 02:57-0800 Alan W. Irwin wrote: > That [build and test of our swig-generated octave bindings on wine] is looking > quite promising.
I got plplot_octave.oct built on wine, but there were conflicting library issues. For example, octave wanted one version of libstdc++-6.dll in Octave/3.2.4_gcc-4.4.0/bin (note that is for MinGW-4.4) that was part of the octave binary download while plplot_octave.oct wanted another version of that file that was part of the MinGW-4.5 download. The result was that octave errored out with a missing symbol (in the MinGW version but not in the octave version of libstdc++-6.dll according to "objdump -p") whenever I tried to dynamically load plplot_octave. I "sort of" solved that by renaming the octave version of libstdc++-6.dll to something else which forced octave to use the MinGW version. That allowed a successful load of plplot_octave, then further plplot commands (such as plinit()) just hung which is a symptom of further library conflict issues between the two MinGW versions of the libraries or possibly other issues as well. This is not a Windows problem. You would get similar issues on Linux if you tried to use, say, RedHat libraries on Debian. I think the only reliable away around library version conflict issues is to build octave with the same compiler version used to build plplot_octave. But octave itself has a huge number of dependencies which would have to be built as well with that same MinGW compiler version. So ultimately what is needed here is a coherent MingGW-based distribution of software. We actually have the start of that with the octave binary distribution; Octave/3.2.4_gcc-4.4.0/bin contains 80 (!) dll's because of the huge number of external dependencies of Octave. But that "distribution" is not complete. So I am giving up on octave for Windows for now until the Octave-forge developers provide a version compatible with MinGW-4.5. (I could also fall back to MinGW-4.4 myself, but then I would lose the huge convenience of the automatic installer that is available for MinGW-4.5 (and the latest version of MSYS). In fact, I think that huge convenience factor is going to motivate a lot of Windows packagers to move from earlier MinGW versions to MinGW-4.5 so I don't think my wait for octave (and also the Qt4 suite of libraries which have similar issues) to move to MinGW-4.5 will be too long. Note, although my Octave on Windows efforts are temporarily suspended the primary motivation (i.e., our group knows how to deal with swig typemap issues but not matwrap issues) remains for implementing swig-generated octave binding. For example, with swig-generated octave bindings Andrew tells us there is a chance of dealing with the API issues for example 19 in octave. Anyhow, for the next few days I plan to see how far I can get with implementing correct swig/octave typemaps using the matwrap-generated interface code as a guide for what to do with the typemaps. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
