From: Rafael L. <rla...@us...> - 2004-01-14 12:02:18
|
* Alan W. Irwin <ai...@us...> [2004-01-14 02:21]: > I think it is important to solve the octave linking issue on MacOS X before > we release. If that means a delay until I can perfect my solution or Joao > can get his preferred solution to work or you can get your preferred > solution to work then so be it. I would prefer to fix the Octave bindings building problem on MacOS X post-release (e.g. 5.3.1). This is a problem affecting only one of the PLplot bindings (Octave) in only one of the architectures we are expected to support (MacOS X). IMHO, Your recent changes introduce too much hassle for very little benefit. > I realize you are pressed for time, but you should actually look at the > mkoctfile script from version 2.1.50 and actually run mkoctfile --help which > documents all those flags. The man page must be out of date relative to > mkoctfile --help because these are all public flags which are not internal. > In fact, the above flags are exactly what is used to generate the above g++ > line on Mac OS X or the appropriate g++ line on your Debian unstable system. > Also, over time mkoctfile has added to the public flags that are accessible > with the -p option, but never subtracted. So I think characterizing this as > a maintenance nightmare is not a fair assessment. I was thinking about the future. Each time the Octave is built with a new library (and this happens quite frequently, like in the fftw case), we will have to change the OCTAVELIBCMD line. *_That_* is the nightmare, which is completely bypassed when using mkoctfile directly. > > 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. > > You are missing the point of OCTAVELIBCMD. It is guaranteed to > collect _exactly_ the same octave-related -L and -l flags that mkoctfile > uses on each system to generate the g++ command. Provided that you always keep in phase with the upstream Octave, see above. > So on Debian stable it reduces to nothing, on Mac OS X (using Koen's > version of mkoctfile) it reduces to > > -L/sw/lib/octave-2.1.50 -loctave -lcruft -loctinterp -L/sw/lib -ldfftw > > Out of curiosity, what does it reduce to on debian unstable? $ MKOCTFILE=mkoctfile $ OCTAVELIBCMD=`$MKOCTFILE -p LFLAGS && \ $MKOCTFILE -p LIBOCTAVE && \ $MKOCTFILE -p LIBCRUFT && \ $MKOCTFILE -p LIBOCTINTERP && \ $MKOCTFILE -p BLAS_LIBS && \ $MKOCTFILE -p FFTW_LIBS` $ echo $OCTAVELIBCMD -L/usr/lib/octave-2.1.52 -loctave -lcruft -loctinterp /usr/lib/liblapack2.so /usr/lib/libblas2.so -lfftw > > 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? > > An oversight that is an extremely easy issue to fix. Hopefully. > > 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. > > Sounds like a permissions problem to me. Again, it should be easy to fix. Hopefully. > As I understand it the lintian check occurs after the build? Of course. Lintian acts on the *.deb files. > Does that mean the build went okay with no problems other than the > Debian policy issues you have mentioned and which should be easy to fix? Yes. But I did not have time to check the Octave results. > > 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. > > Umm. I already mentioned this issue, and in fact I asked you for help with > it. This could easily be solved by the documented -shrext option to > libtool. So far I have not got it to work, but I am investigating. This is the real show-stopper for now. I do not have time to investigate the -shrext option now. At any rate, I would prefer spending my time now in trying to find a better solution to the problem. -- Rafael |