Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Joao C. <jc...@fe...>]

On Wednesday 26 March 2003 01:02, Alan W. Irwin wrote:
> Here is an update on the netbsd status.
>
> On Mon, 24 Mar 2003, Alan W. Irwin wrote:
> > Here is the current status of plplot on netbsd.
> >
> > There is one issue that is a real showstopper for netbsd (and perhaps
> > other unices).  The ./get-drv-info helper application segfaults when it
> > tries to obtain information about the xwin driver.
>
> This is still a showstopper with Rafael's patched debian version of
> libtool.
>
> ./get-drv-info xwin
> Segmentation fault (core dumped)
>
> ./get-drv-info gd
> jpeg:JPEG file:0:gd:40:jpeg
> png:PNG file:0:gd:39:png
>
> Rafael, can you recommend some later version of libtool for me
> to try?  Are they close to their next release now?
>
> Joao, do you have
> any OSF1 results for using the
>
> ./get-drv-info xwin
>
> command in the drivers directory?

Yes, it is OK:

bash-2.01$ ./get-drv-info gd
Could not open driver module gd
bash-2.01$ ./get-drv-info ps
ps:PostScript File (monochrome):0:ps:29:psm
psc:PostScript File (color):0:ps:30:pscbash-2.01$ 
bash-2.01$ ./get-drv-info xwin
xwin:X-Window (Xlib):1:xwin:5:xwbash-2.01$ 

I still had not time to test the isnan configure issue.

Joao

>
> > Here are some additional issues that need to be addressed but which I can
> > bypass for now using --disable-tcl --without-freetype --disable-octave
>
> The tcl issue is still not addressed.
>
> I had some correspondence with Andrew about the freetype issue. 
> Apparently, ft2build.h is considered an essential front end to more
> volatile changes in other freetype2 headers so it should not be bypassed. 
> Since netbsd did not include ft2build.h, our conclusion is freetype2
> packaging is broken for netbsd.  For all further netbsd tests I will turn
> off freetype using --without-freetype.
>
> Rafael's perl changes allowed me to try octave on netbsd, but I conclude
> mkoctfile or the octave installation is broken there.  The compile step is
> done with the same warning messages as on the Linux side of things, but the
> link step is done with a bare
>
> ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd
>
> command which generates the following messages:
>
> ld: warning: cannot find entry symbol _start; defaulting to 00014d98
> plplot_octave.o: In function `str_vec_compare(void const *, void const *)':
> plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char,
> string_char_traits<char>, __default_alloc_template<false, 0>
> >::compare(basic_string<char, string_char_traits<char>,
> __default_alloc_template<false, 0> > const &, unsigned long, unsigned long)
> const' plplot_octave.o: In function `_arraylen(octave_value const &)':
> plplot_octave.o(.text+0x1b00): undefined reference to `umul'
> plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list
> const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to
> `octave_value::octave_value(void)'

This looks like a libstdc question? Or a static Octave? Is Octave compiled 
with shared libs? What do

ldd `which octave`

reports? Does liboctinterp/liboctave/libcruft appears?

...
liboctinterp.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctinterp.so.2.1.36 
 liboctave.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctave.so.2.1.36 
libcruft.so.2.1.36 => /usr/local/lib/octave-2.1.36/libcruft.so.2.1.36 
...

>
> plus hundreds more of these undefined references.
>
> The equivalent command on the Linux side is fairly similar:
>
> /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs
> -lplplotd
>
> but of course with no warnings or messages.
>
> mkoctfile is supposed to have some sort of cross-platform support, but as
> far as I can tell when comparing the Linux and netbsd versions there is
> little difference between them except the link command differences above.
>
> It may be that in order to overcome this problem, we would have to go to a
> more powerful cross-platform solution such as libtool.  Rafael and Joao
> have not been keen on replacing mkoctfile with libtool to build the octave
> interface to plplot, but if they change their minds (after the current
> release; it is too late in this release cycle to try it), netbsd is a good
> test platform for a libtool solution. For example, I am glad I moved from
> the python native solution we had before (setup.py) to libtool to build the
> python interface to plplot.  That seems to work fine for netbsd (and every
> other platform where we have tried it) while the native method had lots of
> ifs, ands, and buts from one platform to the next.
>
> For now, I will avoid octave on netbsd by --disable-octave.
>
> So the scorecard is two issues (freetype and octave) which we have resolved
> by disabling since something is broken on netbsd, tcl/tk (still
> to be resolved), and the segfault which continues to be a major worry.
>
> Alan
> __________________________
> Alan W. Irwin
> email: ir...@be...
> phone: 250-727-2902
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the Canadian Centre for Climate Modelling and
> Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting
> software package (plplot.org).
>
> __________________________
>
> Linux-powered Science
> __________________________
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel