From: Rafael L. <rla...@us...> - 2004-01-14 09:18:15
|
* Alan W. Irwin <ai...@us...> [2004-01-13 23:23]: > If it turns out that after you have tried it and after I have answered any > issues you can find in the results it provides, you still don't like the > design, then we can try something else [so long as it works!] or else revert > back my changes and write-off Mac OS X octave until after the release. But > give this solution a good test first, please. I think any results issues > that you turn up will be easy to solve since it is all pretty generic > autotools stuff that we are used to. I got a two hours "launching window" this morning and I was planning to release the tarball candidate for 5.3.0. However, after I tested CVS HEAD today, I found a couple of issues with the recent changes in the Octave bindings. See below. Since the problems are serious enough and I will be very busy in the next days, I will have to push the release back by roughly one week, unless the changes are reverted in CVS. I am sorry about this, but I was not expecting a so huge change just before the release of the tarball candidate. The issues are: 1) Maintenance nightmare with OCTAVELIBCMD We have now in sysloc.in: OCTAVELIBCMD=`$MKOCTFILE -p LFLAGS && \ $MKOCTFILE -p LIBOCTAVE && \ $MKOCTFILE -p LIBCRUFT && \ $MKOCTFILE -p LIBOCTINTERP && \ $MKOCTFILE -p BLAS_LIBS && \ $MKOCTFILE -p FFTW_LIBS` This will introduce a maintenance burden in sysloc.in, because the above configuration variables (BLAS_LIBS, LIBCRUFT, etc) are internal settings of Octave and are even not advertised in man mkoctfile. They are subject to change and we should not use them. Besides that, if you look again at the build log on MacOS X sent by Koen you will see: g++ -bundle -bundle_loader /sw/bin/octave-2.1.50 -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd -L/sw/lib/octave-2.1.50 -loctave -lcruft -loctinterp -framework vecLib -L/sw/lib -ldfftw The Octave libraries are already correctly added by mkoctfile, so that OCTAVELIBCMD would be useless. As I predict, trying to replace mkoctfile by libtool is like opening a can of worms. 2) Forced rpath This is a nasty problem for the Debian packages. In the previous situation there was a SET_LDRPATH variable in bindings/octave/Makefile.am that coped nicely with the configure with_rpath variable. Why was it removed? 3) Debian packaging problem When I build the Debian packages and run lintian (the Debian checker) on them, I get the error: E: octave-plplot: shlib-with-executable-bit usr/lib/octave/site/oct/i386-pc-linux-gnu/plplot_octave.oct 0755 I have no idea about the origin of the problem, but as a matter of fact I am forbidden to upload the packages to the Debian repository, because the above error is a Policy violation. 4) Shared object naming breaks portability This is the worst problem of all. In bindings/octave/Makefile.am we have: plplot_octave.oct: .libs/plplot_octave.so cp .libs/plplot_octave.so plplot_octave.oct This will prevent users in Cygwin (.dll), MAcOS (.dylib), HPUX (.sl), etc of building the Octave bindings, because it relies on the .so suffix. This is a *_huge_* step backwards. -- Rafael |