plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-02-07 14:51]:

> I measure the time that your code in plInitDispatchTable() takes to load 
> all drivers, and it is only 20ms (wall clock) for all 33 drivers, on a 
> P3@700MHz (with a small but continuous load of 1). It looks like it is 
> pretty efficient.
> 
> Your concerns that dlopen() would load all libraries that a driver needs 
> does not apply, as this would only happens if some drivers code is 
> executed, which is not the case. As libtool's info says:
> 
>     "Unresolved symbols in the module are resolved using
>      its dependency libraries"
> 
> As the symbols you are looking for are in the modules, no further 
> loading will occur.
> 
> Thus, given that the current implementation is efficient enough, avoids 
> the need of another program to build the drivers.rc file, is fully 
> dynamic because if more drivers are added to the directory they will be 
> recognized without further intervention,... lets keep it as is.

Thanks for addressing those two points which I was too lazy to evaluate
(efficiency and loading of libraries).  Although I am not totally happy with
the current implementation, I will keep it as is for now.

I am pretty convinced that the memory management problems that you had when
using lt_dlclose come only from the libltdl code (use of a private realloc
along with a system's malloc).  This has been discussed in the libtool
mailing list and fixed in the libtool's cvs tree.  There are good news here:
version 1.5 is coming soon:

   http://mail.gnu.org/archive/html/libtool/2003-02/msg00014.html

Next step: Debian packages.

-- 
Rafael

[Plplot-devel] Recent plplot/doc/docbook/configure.ac CVS commit

[Alan W. I. <ir...@be...>]

Works like a charm!

I can now build the documentation again on Debian using the latest autotools
from the FSF (the same tool versions that work for the rest of the PLplot
build).

Thanks, Rafael!

All developers: now that that autotools roadblock has been cleared, please
let the list know of success/failure of documentation build for your Linux
platform of choice. Note you will need docbook2X and certain perl modules
installed on your system as well as the latex suite installed with plenty of
resources (See README.developers.)

I doubt I will be able to get to it this weekend, but I plan to try building
the documentation on RH7.3 and RH8.0 the next chance I get.

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
__________________________

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Fri, 7 Feb 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-02-06 18:52]:
>
> > The most important point, however, is you do see segfaults on your machine
> > so you have confirmed there is a severe problem, and you therefore have
> > something that you can debug for your situation.
> >
> > Good luck in figuring this out!
>
> I think I found the source of the problem, see my last cvs commit.  Could
> you guys confirm that HEAD works for you now?

Yes with a qualification.

No segfaults for ./x01c with the "Joao" configuration.

However,

valgrind --num-callers=100 ./x01c -dev psc -o temp.ps

reports 3 memory management errors (all described as "Conditional jump or
move depends on uninitialised value(s)") having to do with the call to
lt_dlopenext at plcore.c line 1634. Memory management errors with this
description are often non-consequential because they typically come from
code which jumps depending on the truth of condition1 OR condition2 where
condition1 depends on the uninitialized values and condition2 is true (and
thus the jump occurs correctly despite the memory management error).  To get
rid of this valgrind error message when it occurred directly within PLplot
code, I simply used condition2 OR condition1 so that condition1 was never
executed when condition2 was true.

The actual jump with the memory management problem occurs some 20 layers
deeper into libltl and the libraries it calls so ordinarily you would
dismiss it as a problem with library code, but I pursued this further and
think it is solely a problem with the xwin device.  First, note that the
exact same valgrind test produces no such messages for the 5.2.0 version
with the psc device.  However, *with 5.2.0* the same 3 valgrind error
messages are produced using -dev xwin. So I believe -dev xwin is just not
quite set up correctly to be dynamic, but the rest of the devices are okay.
The reason I say this is the new code loops over every device (as a
replacement for drivers.db) and I attribute the 3 valgrind messages I found
above to the xwin device.

Summary: the new code loops over every device so will trigger the
complete collection of valgrind errors for all devices (just xwin in this
case) while the old code just looked at the user-specified device so gets no
valgrind errors (except when the user specified xwin).

So to become valgrind-clean we should do the following:

(1) Figure out what is wrong with the dynamic setup of -dev xwin compared to
*all* the other devices.

(2) Deal with the many memory leaks (valgrind defines these to be unfreed
memory at end of programme).  valgrind found all the ones specific to PLplot
are generated by the dynamic driver code and some even had clobbered
pointers by end of programme.  For more details about these problems, please
see the PROBLEMS file, and
http://sourceforge.net/mailarchive/message.php?msg_id=1785861.

(3) Deal with the recent problem Rafael had with using lt_dlclose.  That
problem may automatically get solved once the memory leaks are dealt with.

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
__________________________

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

On Wednesday 05 February 2003 16:55, Jo=E3o Cardoso wrote:
| On Wednesday 05 February 2003 13:55, Rafael Laboissiere wrote:
| | * Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]:
| | >    c) At build time (not configuration time), a small C program
| | > dlopen the <driver>.c files, get the symbols described above and
| | > write the associated device entries in <driver>.rc (or whichever
| | > name).
| |
| | Just to make things a bit more concrete, here is the design that I
| | have in mind.  I will take the ps.c driver as an example.  The
| | following global variables will be defined in the driver source:
| |
| |     char* DEVICES_ps      =3D "ps:psc";
| |
| |     char* DESCRIPTION_ps  =3D "PostScript File (monochrome)";
| |     int   TYPE_ps         =3D plDevType_FileOriented;
| |     int   SEQNUM_ps       =3D 29;
| |     char* SYMTAG_ps       =3D "psm";
| |
| |     char* DESCRIPTION_psc =3D "PostScript File (color)";
| |     int   TYPE_psc        =3D plDevType_FileOriented;
| |     int   SEQNUM_psc      =3D 30;
| |     char* SYMTAG_psc      =3D "psc";
| |
| | Of course, these variables should be used in the
| | plD_dispatch_init_* functions.  In the case of ps.c:
| |
| |     ps_dispatch_init_helper( pdt,
| |                              DESCRIPTION_ps, "ps",
| |                              TYPE_ps, SEQNUM_ps,
| |                              (plD_init_fp) plD_init_psm );
| |
| |     ps_dispatch_init_helper( pdt,
| |                              DESCRIPTION_psc, "psc",
| |                              TYPE_psc, SEQNUM_psc,
| |                              (plD_init_fp) plD_init_psc );
| |
| | This will insure that things are not defined twice in different
| | places (like with the current DEVICE_INFO_* variable).
| |
| | The small C program that will generate the <driver>.rc file from
| | the <driver>.la file, would do: (1) dlopen the module; (2) get the
| | DEVICES_* symbol and parse its device components (in the ps.c
| | exemple, that would be "ps" and "psc"); (3) for each one of the
| | devices found, get the symbols DESCRIPTION_<dev>, TYPE_<dev>,
| | SEQNUM_<dev>, and SYMTAG_<dev>; (4) create the temp file that is
| | parsed by Geoff's code. (This could be improved along Joao's
| | suggestion of creating a structure instead of writing the
| | information in a temp file.)
| |
| | We have to decide first whether it is not worth abandoning the
| | current approach and adopting this "cached info" approach above.

Now that HEAD is working again. lets continue.

I measure the time that your code in plInitDispatchTable() takes to load=20
all drivers, and it is only 20ms (wall clock) for all 33 drivers, on a=20
P3@700MHz (with a small but continuous load of 1). It looks like it is=20
pretty efficient.

Your concerns that dlopen() would load all libraries that a driver needs=20
does not apply, as this would only happens if some drivers code is=20
executed, which is not the case. As libtool's info says:

    "Unresolved symbols in the module are resolved using
     its dependency libraries"

As the symbols you are looking for are in the modules, no further=20
loading will occur.

Thus, given that the current implementation is efficient enough, avoids=20
the need of another program to build the drivers.rc file, is fully=20
dynamic because if more drivers are added to the directory they will be=20
recognized without further intervention,... lets keep it as is.

Joao

|
| I decided to give it a try but got a seg fault:
|
| [jcard@feup] gdb x01c
| (gdb) run -dev xwin
| Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c
| -dev xwin
|
| Program received signal SIGSEGV, Segmentation fault.
| 0x0806a46e in lt_dlsym (handle=3D0x807b0e0,
|     symbol=3D0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
| 3330      lensym =3D LT_STRLEN (symbol) + LT_STRLEN
| (handle->loader->sym_prefix)
| (gdb) where
| #0  0x0806a46e in lt_dlsym (handle=3D0x807b0e0,
|     symbol=3D0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
| #1  0x08053d38 in plInitDispatchTable () at plcore.c:1638
| #2  0x08049b9d in plMergeOpts (options=3D0x8073500,
|     name=3D0x11 <Address 0x11 out of bounds>, notes=3D0x11) at
| plargs.c:699 #3  0x08049362 in main ()
| #4  0x400674a2 in __libc_start_main () from /lib/libc.so.6
|
| | There is also Joao's suggestion for dynamically building the
| | drivers.db, but I am too lazy to implement that (and I am not sure
| | it is a superior approach).
| |
| | What do you think?  I accept suggestions for better variable names.
|
| -------------------------------------------------------
| This SF.NET email is sponsored by:
| SourceForge Enterprise Edition + IBM + LinuxWorld
| http://www.vasoftware.com
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-02-07 14:21]:

> Yes,
> 
> [jcard@feup] ./bootstrap.sh
> Running aclocal (GNU automake) 1.7.2... done
> Running autoheader (GNU Autoconf) 2.57... done
> Running automake (GNU automake) 1.7.2... done
> Running libtoolize (GNU libtool) 1.4.3... done
> Running autoconf (GNU Autoconf) 2.57... done
> 
> ./configure --enable-octave --enable-dyndrivers --disable-static
>  --with-double --prefix=/usr/local/test
> 
> And after install x01c works.

Uff... I am relieved.  I can go out for the weekend knowing that HEAD is not
in a completely bad shape.

The memory management problems are still there, though...

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

On Friday 07 February 2003 08:30, Rafael Laboissiere wrote:
| * Alan W. Irwin <ir...@be...> [2003-02-06 18:52]:
| > The most important point, however, is you do see segfaults on your
| > machine so you have confirmed there is a severe problem, and you
| > therefore have something that you can debug for your situation.
| >
| > Good luck in figuring this out!
|
| I think I found the source of the problem, see my last cvs commit.=20
| Could you guys confirm that HEAD works for you now?

Yes,

[jcard@feup] ./bootstrap.sh
Running aclocal (GNU automake) 1.7.2... done
Running autoheader (GNU Autoconf) 2.57... done
Running automake (GNU automake) 1.7.2... done
Running libtoolize (GNU libtool) 1.4.3... done
Running autoconf (GNU Autoconf) 2.57... done

=2E/configure --enable-octave --enable-dyndrivers --disable-static
 --with-double --prefix=3D/usr/local/test

And after install x01c works.

Joao

Re: [Plplot-devel] Problem using shared library of plplotter.

[Vince D. <vi...@sa...>]

On Fri, 7 Feb 2003, Piyush Laddha wrote:

>  Hi All,
>
>  I tried building plplot5.2.0 source code on VC++ 6.0 windows NT and created plplot520.dll. But facing problem when using this dll in wrapped application of  tcl/tk using load_unsupported. It is giving error in startup script because of load_unsupported where as it works properly with tcl/tk command prompt wish84

Can you explain what you mean by 'load_unsupported' ?

Does the Plplotter.kit that I have made available work for you?

>  Did I  miss anything while building ?
>
> Is there any document that can explain what all files has to be  included while building shared library of plplotter for tcl/tk,on windowsNT using VC++6.0. I am using active tcl 8.4.

No document, but if you copy what is in the starkit that I made, it should
work.

cheers,

Vince.

[Plplot-devel] Problem using shared library of plplotter on Solaris

[Piyush L. <pi...@da...>]

Hi all,

I have built Plplot5.2.0 on Solaris(8) platform. I have used following =
configuration to build the shared library on the Solaris
./configure --disable-dyndrivers --disable-tek4010f --disable-conex =
--disable-vlt --disable-versaterm --disable-mskermit --disable-tek4107 =
--disable-tek4010 --disable-xterm --disable-pstex --disable-psc =
--disable-pbm --disable-ntk --disable-ljiip --disable-ljii =
--disable-linuxvga --disable-imp --enable-jpeg --disable-lj_hpgl =
--disable-hp7580 --disable-hp7470 --disable-gnome --disable-png =
--disable-cgm --disable-dg300 --disable-xfig --disable-ljii =
--disable-gtktest --disable-pyton --disable-f77 --enable-itcl =
--enable-java --enable-tcl --enable-tk --disable-cxx --disable-octave
I am getting following behaviour...

-> When I try to load "plplotter520.so" using statement "load =
plplotter520.so Plplotter" from     the directory where Plplotter is =
installed, say /usr/ActiveTcl/lib/plplotter then it returns 0 and works =
fine for single instance of plotter.

-> When i try to load "plplotter520.so" from any other directory but =
it's parent directory using statement=20

"load plplotter520.so Plplotter" then it flags error that =
usr/ActiveTcl/lib/plplot5.2.0/plplotter520.so": ld.so.1: wish8.4: fatal: =
plplotter520.so open failed: No such file or directory=20
And when I use  "load usr/ActiveTcl/lib/plplot5.2.0/plplotter520.so =
Plplotter" then it does not give the above mentioned error but neither =
does it return "0" and after that it does not work properly. It even =
does not recognize "Plplotwin" and flags it as an "invalid command".

Please tell me that what could have gone wrong.

Regards ,

Piyush L.

[Plplot-devel] Problem using shared library of plplotter.

[Piyush L. <pi...@da...>]

 Hi All,
=20
 I tried building plplot5.2.0 source code on VC++ 6.0 windows NT and =
created plplot520.dll. But facing problem when using this dll in wrapped =
application of  tcl/tk using load_unsupported. It is giving error in =
startup script because of load_unsupported where as it works properly =
with tcl/tk command prompt wish84
=20
 Did I  miss anything while building ?

Is there any document that can explain what all files has to be  =
included while building shared library of plplotter for tcl/tk,on =
windowsNT using VC++6.0. I am using active tcl 8.4.
=20
 Thanks,
 Regards,
 Piyush L.

[Plplot-devel] Problems in tcl/tk driver on Solaris platform.

[Piyush L. <pi...@da...>]

bash-2.03$ ./configure --disable-dyndrivers --disable-tek4010f =
--disable-conex --disable-vlt --disable-versaterm --disable-mskermit =
--disable-tek4107 --disable-tek4010 --disable-xterm --disable-pstex =
--disable-psc --disable-pbm --disable-ntk --disable-ljiip --disable-ljii =
--disable-linuxvga --disable-imp --enable-jpeg --disable-lj_hpgl =
--disable-hp7580 --disable-hp7470 --disable-gnome --disable-png =
--disable-cgm --disable-dg300 --disable-xfig --disable-ljii =
--disable-gtktest --disable-pyton --disable-f77 --enable-itcl =
--enable-java --enable-tcl --enable-tk --disable-cxx --disable-octave=0A=
No defaults file found, performing full configure.=0A=
No defaults file found, performing full configure.=0A=
checking for a BSD-compatible install... ./install-sh -c=0A=
checking whether build environment is sane... yes=0A=
checking for gawk... no=0A=
checking for mawk... no=0A=
checking for nawk... nawk=0A=
checking whether make sets $(MAKE)... yes=0A=
checking for style of include used by make... GNU=0A=
checking for gcc... gcc=0A=
checking for C compiler default output... a.out=0A=
checking whether the C compiler works... yes=0A=
checking whether we are cross compiling... no=0A=
checking for suffix of executables... =0A=
checking for suffix of object files... o=0A=
checking whether we are using the GNU C compiler... yes=0A=
checking whether gcc accepts -g... yes=0A=
checking for gcc option to accept ANSI C... none needed=0A=
checking dependency style of gcc... gcc3=0A=
checking for gcc option to accept ANSI C... none needed=0A=
checking build system type... sparc-sun-solaris2.8=0A=
checking host system type... sparc-sun-solaris2.8=0A=
checking for ld used by GCC... /usr/local/sparc-sun-solaris2.8/bin/ld=0A=
checking if the linker (/usr/local/sparc-sun-solaris2.8/bin/ld) is GNU =
ld... yes=0A=
checking for /usr/local/sparc-sun-solaris2.8/bin/ld option to reload =
object files... -r=0A=
checking for BSD-compatible nm... /usr/local/bin/nm -B=0A=
checking for a sed that does not truncate output... /usr/xpg4/bin/sed=0A=
checking whether ln -s works... yes=0A=
checking how to recognise dependent libraries... pass_all=0A=
checking command to parse /usr/local/bin/nm -B output... ok=0A=
checking how to run the C preprocessor... gcc -E=0A=
checking for egrep... egrep=0A=
checking for ANSI C header files... yes=0A=
checking for sys/types.h... yes=0A=
checking for sys/stat.h... yes=0A=
checking for stdlib.h... yes=0A=
checking for string.h... yes=0A=
checking for memory.h... yes=0A=
checking for strings.h... yes=0A=
checking for inttypes.h... yes=0A=
checking for stdint.h... no=0A=
checking for unistd.h... yes=0A=
checking dlfcn.h usability... yes=0A=
checking dlfcn.h presence... yes=0A=
checking for dlfcn.h... yes=0A=
checking for ranlib... ranlib=0A=
checking for strip... strip=0A=
checking for objdir... .libs=0A=
checking for gcc option to produce PIC... -fPIC=0A=
checking if gcc PIC flag -fPIC works... yes=0A=
checking if gcc static flag -static works... yes=0A=
checking if gcc supports -c -o file.o... yes=0A=
checking if gcc supports -c -o file.lo... yes=0A=
checking if gcc supports -fno-rtti -fno-exceptions... yes=0A=
checking whether the linker (/usr/local/sparc-sun-solaris2.8/bin/ld) =
supports shared libraries... yes=0A=
checking how to hardcode library paths into programs... immediate=0A=
checking whether stripping libraries is possible... yes=0A=
checking dynamic linker characteristics... solaris2.8 ld.so=0A=
checking if libtool supports shared libraries... yes=0A=
checking whether to build shared libraries... yes=0A=
checking whether to build static libraries... yes=0A=
checking whether -lc should be explicitly linked in... yes=0A=
creating libtool=0A=
checking for X... libraries , headers =0A=
checking for main in -lX11... yes=0A=
"Uhhh." =0A=
warning: Java Native Interface include file not found=0A=
checking for main in -lgd... yes=0A=
checking for main in -lpng... no=0A=
but found in /usr/lib=0A=
checking for main in -ljpeg... yes=0A=
checking for main in -lz... yes=0A=
checking for png support in libgd... no: png driver disabled=0A=
checking for jpeg support in libgd... no: jpeg driver disabled=0A=
checking for libtcl... /usr/ActiveTcl/lib/libtcl8.4.so=0A=
checking itclDecls.h usability... no=0A=
checking itclDecls.h presence... yes=0A=
configure: WARNING: itclDecls.h: present but cannot be compiled=0A=
configure: WARNING: itclDecls.h: check for missing prerequisite headers?=0A=
configure: WARNING: itclDecls.h: proceeding with the preprocessor's =
result=0A=
configure: WARNING:     ## ------------------------------------ ##=0A=
configure: WARNING:     ## Report this to bug...@gn.... ##=0A=
configure: WARNING:     ## ------------------------------------ ##=0A=
checking for itclDecls.h... yes=0A=
checking for libitcl... =0A=
/usr/ActiveTcl/lib/itcl3.2/libitcl3.2.so=0A=
/usr/ActiveTcl/lib/itcl3.2=0A=
 yes /usr/ActiveTcl/include=0A=
checking for tkInt.h... /usr/ActiveTcl/include/tkInt.h=0A=
/usr/ActiveTcl/include=0A=
checking for tclInt.h... /usr/ActiveTcl/include/tclInt.h=0A=
checking for libtk... /usr/ActiveTcl/lib/libtk8.4.so=0A=
checking for libitk... /usr/ActiveTcl/lib/itk3.2/libitk3.2.so=0A=
checking for Python.h... no=0A=
warning: can't find Python.h, setting enable_python to no=0A=
checking for g++... g++=0A=
checking whether we are using the GNU C++ compiler... yes=0A=
checking whether g++ accepts -g... yes=0A=
checking dependency style of g++... gcc3=0A=
checking for ANSI C header files... (cached) yes=0A=
checking for unistd.h... (cached) yes=0A=
checking termios.h usability... yes=0A=
checking termios.h presence... yes=0A=
checking for termios.h... yes=0A=
checking for sys/wait.h that is POSIX.1 compatible... yes=0A=
checking for caddr_t... yes=0A=
checking for pid_t... yes=0A=
checking for unistd.h... (cached) yes=0A=
checking vfork.h usability... no=0A=
checking vfork.h presence... no=0A=
checking for vfork.h... no=0A=
checking for fork... yes=0A=
checking for vfork... yes=0A=
checking for working fork... yes=0A=
checking for working vfork... (cached) yes=0A=
checking for popen... yes=0A=
checking for usleep... yes=0A=
checking for isinf... no=0A=
checking for finite... yes=0A=
checking for gethostbyname... no=0A=
checking for gethostbyname in -lnsl... yes=0A=
checking for connect... no=0A=
checking for connect in -lsocket... yes=0A=
checking for remove... yes=0A=
checking for shmat... yes=0A=
checking for IceConnectionNumber in -lICE... yes=0A=
checking for dynamic drivers... =0A=
configure: creating ./config.status=0A=
config.status: creating Makefile=0A=
config.status: creating src/Makefile=0A=
config.status: creating include/Makefile=0A=
config.status: creating lib/Makefile=0A=
config.status: creating bindings/Makefile=0A=
config.status: creating bindings/c++/Makefile=0A=
config.status: creating bindings/f77/Makefile=0A=
config.status: creating bindings/python/Makefile=0A=
config.status: creating bindings/tcl/Makefile=0A=
config.status: creating bindings/tk/Makefile=0A=
config.status: creating bindings/octave/Makefile=0A=
config.status: creating bindings/octave/PLplot/Makefile=0A=
config.status: creating bindings/octave/PLplot/support/Makefile=0A=
config.status: creating bindings/octave/demos/Makefile=0A=
config.status: creating bindings/octave/misc/Makefile=0A=
config.status: creating bindings/java/Makefile=0A=
config.status: creating bindings/java/config.java=0A=
config.status: creating drivers/Makefile=0A=
config.status: creating examples/Makefile=0A=
config.status: creating examples/c/Makefile=0A=
config.status: creating examples/c/Makefile.examples=0A=
config.status: creating examples/c++/Makefile=0A=
config.status: creating examples/c++/Makefile.examples=0A=
config.status: creating examples/f77/Makefile=0A=
config.status: creating examples/f77/Makefile.examples=0A=
config.status: creating examples/python/Makefile=0A=
config.status: creating examples/python/plplot_python_start.py=0A=
config.status: creating examples/tcl/Makefile=0A=
config.status: creating examples/tk/Makefile=0A=
config.status: creating examples/tk/Makefile.examples=0A=
config.status: creating examples/java/Makefile=0A=
config.status: creating test/Makefile=0A=
config.status: creating test/plplot-test.sh=0A=
config.status: creating utils/Makefile=0A=
config.status: creating scripts/Makefile=0A=
config.status: creating plplot.pc=0A=
config.status: creating plplot-double.pc=0A=
config.status: creating include/plConfig.h=0A=
config.status: creating include/plDevs.h=0A=
config.status: executing depfiles commands=0A=
configure: configuring in libltdl=0A=
configure: running /bin/bash './configure' --prefix=3D/usr/local  =
'--disable-dyndrivers' '--disable-tek4010f' '--disable-conex' =
'--disable-vlt' '--disable-versaterm' '--disable-mskermit' =
'--disable-tek4107' '--disable-tek4010' '--disable-xterm' =
'--disable-pstex' '--disable-psc' '--disable-pbm' '--disable-ntk' =
'--disable-ljiip' '--disable-linuxvga' '--disable-imp' '--enable-jpeg' =
'--disable-lj_hpgl' '--disable-hp7580' '--disable-hp7470' =
'--disable-gnome' '--disable-png' '--disable-cgm' '--disable-dg300' =
'--disable-xfig' '--disable-ljii' '--disable-gtktest' '--disable-pyton' =
'--disable-f77' '--enable-itcl' '--enable-java' '--enable-tcl' =
'--enable-tk' '--disable-cxx' '--disable-octave' =
--enable-ltdl-convenience --cache-file=3D/dev/null --srcdir=3D.=0A=
loading cache /dev/null=0A=
./configure: .: /dev/null: not a regular file=0A=
checking for a BSD compatible install... ./../install-sh -c=0A=
checking whether build environment is sane... yes=0A=
checking whether make sets ${MAKE}... yes=0A=
checking for working aclocal... missing=0A=
checking for working autoconf... missing=0A=
checking for working automake... missing=0A=
checking for working autoheader... missing=0A=
checking for working makeinfo... missing=0A=
checking whether to enable maintainer-specific portions of Makefiles... =
no=0A=
checking for gcc... gcc=0A=
checking whether the C compiler (gcc  ) works... yes=0A=
checking whether the C compiler (gcc  ) is a cross-compiler... no=0A=
checking whether we are using GNU C... yes=0A=
checking whether gcc accepts -g... yes=0A=
checking for working const... yes=0A=
checking for inline... inline=0A=
checking for Cygwin environment... no=0A=
checking for mingw32 environment... no=0A=
checking how to run the C preprocessor... gcc -E=0A=
checking host system type... sparc-sun-solaris2.8=0A=
checking build system type... sparc-sun-solaris2.8=0A=
checking for ld used by GCC... /usr/local/sparc-sun-solaris2.8/bin/ld=0A=
checking if the linker (/usr/local/sparc-sun-solaris2.8/bin/ld) is GNU =
ld... yes=0A=
checking for /usr/local/sparc-sun-solaris2.8/bin/ld option to reload =
object files... -r=0A=
checking for BSD-compatible nm... /usr/local/bin/nm -B=0A=
checking for a sed that does not truncate output... /usr/xpg4/bin/sed=0A=
checking whether ln -s works... yes=0A=
checking how to recognise dependent libraries... pass_all=0A=
checking for object suffix... o=0A=
checking for executable suffix... no=0A=
checking command to parse /usr/local/bin/nm -B output... ok=0A=
checking for dlfcn.h... yes=0A=
checking for ranlib... ranlib=0A=
checking for strip... strip=0A=
checking for objdir... .libs=0A=
checking for gcc option to produce PIC... -fPIC=0A=
checking if gcc PIC flag -fPIC works... yes=0A=
checking if gcc static flag -static works... yes=0A=
checking if gcc supports -c -o file.o... yes=0A=
checking if gcc supports -c -o file.lo... yes=0A=
checking if gcc supports -fno-rtti -fno-exceptions... yes=0A=
checking whether the linker (/usr/local/sparc-sun-solaris2.8/bin/ld) =
supports shared libraries... yes=0A=
checking how to hardcode library paths into programs... immediate=0A=
checking whether stripping libraries is possible... yes=0A=
checking dynamic linker characteristics... solaris2.8 ld.so=0A=
checking if libtool supports shared libraries... yes=0A=
checking whether to build shared libraries... yes=0A=
checking whether to build static libraries... yes=0A=
checking whether -lc should be explicitly linked in... yes=0A=
creating libtool=0A=
checking for ANSI C header files... yes=0A=
checking for dirent.h that defines DIR... yes=0A=
checking for opendir in -ldir... no=0A=
checking whether gcc supports assert without backlinking... =0A=
checking which extension is used for shared libraries... .so=0A=
checking which variable specifies run-time library path... =
LD_LIBRARY_PATH=0A=
checking for the default library search path... /lib /usr/lib=0A=
checking for objdir... .libs=0A=
checking whether libtool supports -dlopen/-dlpreopen... yes=0A=
checking for shl_load... no=0A=
checking for shl_load in -ldld... no=0A=
checking for dlopen in -ldl... yes=0A=
checking for dlerror... yes=0A=
checking for _ prefix in compiled symbols... no=0A=
checking whether deplibs are loaded by dlopen... yes=0A=
checking for argz.h... no=0A=
checking for error_t... no=0A=
checking for argz_append... no=0A=
checking for argz_create_sep... no=0A=
checking for argz_insert... no=0A=
checking for argz_next... no=0A=
checking for argz_stringify... no=0A=
checking for errno.h... yes=0A=
checking for malloc.h... yes=0A=
checking for memory.h... yes=0A=
checking for stdlib.h... yes=0A=
checking for stdio.h... yes=0A=
checking for ctype.h... yes=0A=
checking for unistd.h... yes=0A=
checking for dl.h... no=0A=
checking for sys/dl.h... yes=0A=
checking for dld.h... no=0A=
checking for string.h... yes=0A=
checking for strchr... yes=0A=
checking for strrchr... yes=0A=
checking for memcpy... yes=0A=
checking for memmove... yes=0A=
checking for strcmp... yes=0A=
updating cache /dev/null=0A=
creating ./config.status=0A=
creating Makefile=0A=
creating config.h=0A=
config.h is unchanged=0A=
Configure results:=0A=
=0A=
command:        ./configure --disable-dyndrivers --disable-tek4010f =
--disable-conex --disable-vlt --disable-versaterm --disable-mskermit =
--disable-tek4107 --disable-tek4010 --disable-xterm --disable-pstex =
--disable-psc --disable-pbm --disable-ntk --disable-ljiip --disable-ljii =
--disable-linuxvga --disable-imp --enable-jpeg --disable-lj_hpgl =
--disable-hp7580 --disable-hp7470 --disable-gnome --disable-png =
--disable-cgm --disable-dg300 --disable-xfig --disable-ljii =
--disable-gtktest --disable-pyton --disable-f77 --enable-itcl =
--enable-java --enable-tcl --enable-tk --disable-cxx --disable-octave=0A=
system:         sparc-sun-solaris2.8=0A=
prefix:         /usr/local=0A=
CC:             gcc =0A=
LIB_TAG:=0A=
devices:         null plmeta ps tek4107f tk tkwin xwin=0A=
=0A=
Available device drivers=0A=
static:          null.lo plmeta.lo ps.lo tek.lo tk.lo tkwin.lo xwin.lo=0A=
dynamic:=0A=
=0A=
with_shlib:     yes             with_double:    no=0A=
with_debug:     no              with_opt:       yes=0A=
with_warn:      no              with_profile:   no=0A=
with_gcc:       no              with_rpath:     yes=0A=
with_freetype:  no=0A=
=0A=
enable_xwin:    yes             enable_tcl:     yes=0A=
enable_tk:      yes             enable_itcl:    yes=0A=
enable_cxx:     no              enable_python:  no=0A=
enable_f77:     no              enable_java:    no=0A=
enable_octave:  no              enable_gnome:   no=0A=
enable_tkwin:   yes

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-06 18:52]:

> The most important point, however, is you do see segfaults on your machine
> so you have confirmed there is a severe problem, and you therefore have
> something that you can debug for your situation.
> 
> Good luck in figuring this out!

I think I found the source of the problem, see my last cvs commit.  Could
you guys confirm that HEAD works for you now?

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Fri, 7 Feb 2003, Rafael Laboissiere wrote:
>
> This is the minimal pair that I found:
>
>     C examples segfault:
>         ./configure --enable-dyndrivers
>
>     C examples work fine:
>         ./configure --enable-dyndrivers --disable-tcl
>
> Alan, could you please confirm the minimal pair above?

Not precisely.  ./configure --enable-dyndrivers --prefix=blah gives me *no*
segfault for ./x01c -dev xwin.  However, when I ran x01c with valgrind, I
did get lots of "invalid reads from memory" messages and an
eventual segfault.

The most important point, however, is you do see segfaults on your machine
so you have confirmed there is a severe problem, and you therefore have
something that you can debug for your situation.

Good luck in figuring this out!

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
__________________________

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Rafael Laboissiere <lab...@ps...> [2003-02-06 23:50]:

> * Alan W. Irwin <ir...@be...> [2003-02-06 10:45]:
> 
> > P.S.  the only options that should affect the C examples are
> > --enable-dyndrivers --with-double (which are common to Rafael and Joao's
> > options) and --disable-static (which Joao has and Rafael does not).
> > 
> > Thus, I bet there is some problem with the present dynamic drivers
> > configuration or implementation that is incompatible with --disable-static.
> > I hope that strong clue allows Rafael to find and fix the problem without
> > too much further effort.
> 
> Well, when I use:
> 
>     ./configure --prefix=/var/tmp/plplot --enable-octave --enable-dyndrivers \
>                 --disable-static --with-double \
>  		--disable-python --disable-tcl --disable-itcl
> 
> then everything works fine.  Notice that the --disable-static option has
> been included above.

I investigated this further and I think that you are following the wrong
trail with --disable-static.  Also, your assumption that the only options
that affect the C examples are --enable-dyndrivers, --with-double, and
--disable-static is wrong.  The option --disable-tcl *does* affect the C
example.

This is the minimal pair that I found:

    C examples segfault:
        ./configure --enable-dyndrivers   

    C examples work fine:
        ./configure --enable-dyndrivers --disable-tcl

I think I am getting close to the source of the problem and that has nothing
to do with --disable-static.

Alan, could you please confirm the minimal pair above?

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-06 10:09]:

> I think you need quotes around the -I option to bootstrap.sh as above
> (contrary to your commit message).  Otherwise, the $1 in bootstrap.sh will
> just catch the -I and miss the rest.

That's fixed, see cvs commit log.

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-06 10:45]:

> P.S.  the only options that should affect the C examples are
> --enable-dyndrivers --with-double (which are common to Rafael and Joao's
> options) and --disable-static (which Joao has and Rafael does not).
> 
> Thus, I bet there is some problem with the present dynamic drivers
> configuration or implementation that is incompatible with --disable-static.
> I hope that strong clue allows Rafael to find and fix the problem without
> too much further effort.

Well, when I use:

    ./configure --prefix=/var/tmp/plplot --enable-octave --enable-dyndrivers \
                --disable-static --with-double \
 		--disable-python --disable-tcl --disable-itcl

then everything works fine.  Notice that the --disable-static option has
been included above.

Weird.

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

P.S.  the only options that should affect the C examples are
--enable-dyndrivers --with-double (which are common to Rafael and Joao's
options) and --disable-static (which Joao has and Rafael does not).

Thus, I bet there is some problem with the present dynamic drivers
configuration or implementation that is incompatible with --disable-static.
I hope that strong clue allows Rafael to find and fix the problem without
too much further effort.

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
__________________________

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Thu, 6 Feb 2003, Alan W. Irwin wrote:
> Next, I will try Joao's set of options starting from fresh checkout.

Everything done identically from fresh checkout except for

./configure --prefix=/usr/local/plplot_at --enable-octave \
--enable-dyndrivers --disable-static --with-double > & configure.out

AND THE ANSWER IS....

immediate segfault from x01c and x08c (I didn't bother to try anything else).

So we really do live in a rational universe.  The problem Joao found, and
I confirmed yesterday still exists, and it depends on the exact configure
options above and disappears if you use Rafael's options.

Rafael, do you confirm this?

Joao, I still think it is important for you to confirm that Rafael's exact
set of options works on your system so we know we are all on the same page.

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
__________________________

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Thu, 6 Feb 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-02-05 16:56]:
>
> > If you had different configure options than Joao and me but are too tired
> > to re-run the test, could you at least tell us what those configuration
> > options are?  I might find they work on my system which would imply the bug
> > is configure option dependent and not autotools version dependent.
>
>
> Here is exactly what I am doing.
>
>     $ rm -rf plplot
>     $ cvs -d rla...@cv...:/cvsroot/plplot co plplot
>     $ cd plplot
>     $ ./bootstrap.sh
>     $ destdir=/var/tmp/plplot
>     $ ./configure  --prefix=$destdir --disable-tcl --disable-itcl \
>                    --disable-python --enable-dyndrivers --with-double
>     $ rm -rf $destdir
>     $ make install
>     $ cd examples/c
>     $ make x01c
>     $ ./x01c -dev xwin


I confirm that set of options works, and we are back in a rational universe
again after 24 hours where I wasn't sure what kind of universe we were in
....;-)

I will need more investigation to see whether Joao's set of options still
don't work.  There is some ambiguity here because I realize there was a
possibility that my old "system" versions of autotools were interfering.
(My path pointed to the new versions, but some of the old configuration
files might have been interfering.) So the first thing I did was remove
those system versions completely.

apt-get --purge remove autoconf libtool
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  autoconf* autoconf2.13* automake1.5* libtool*
  0 packages upgraded, 0 newly installed, 4 to remove and 0  not upgraded.
  Need to get 0B of archives. After unpacking 5022kB will be freed.
  Do you want to continue? [Y/n]
  (Reading database ... 92196 files and directories currently installed.)
  Removing automake1.5 ...
  Removing libtool ...
  Removing autoconf ...
  Removing autoconf2.13 ...
  dpkg - warning: while removing autoconf2.13, directory /etc/autoconf2.13'
not empty so not removed.
Removing diversion of /usr/bin/autoconf to /usr/bin/autoconf2.50 by
autoconf2.13'
Removing diversion of /usr/bin/autoheader to /usr/bin/autoheader2.50 by
autoconf2.13'
Removing diversion of /usr/bin/autoreconf to /usr/bin/autoreconf2.50 by
autoconf2.13'
Purging configuration files for autoconf2.13 ...
root@starling> ls /etc/autoconf2.13/
root@starling> rmdir /etc/autoconf2.13/

(note the autoconf2.13 above which always adds some version uncertainty if
you are using the Debian versions of the autotools.) That is why I keep
urging Rafael to get rid of his Debian versions of autotools to be
consistent with the rest of us, but in this case it apparently does not make
a difference because I confirm his result when I am using the latest stable
version of autotools from FSF.

Fresh plplot checkout as of 16:46 UT.

./bootstrap.sh '-I /home/software/autotools/install/share/libtool/'
Running aclocal (GNU automake) 1.7.2... done
Running autoheader (GNU Autoconf) 2.57... done
Running automake (GNU automake) 1.7.2...configure.ac: installing ./install-sh'
configure.ac: installing ./mkinstalldirs'
configure.ac: installing ./missing'
configure.ac:456: installing ./config.guess'
configure.ac:456: installing ./config.sub'
configure.ac:456: required file ./ltmain.sh' not found
Makefile.am:25: required directory ./libltdl does not exist
bindings/c++/Makefile.am: installing ./depcomp'
drivers/Makefile.am: installing ./compile'
Makefile.am:25: required directory ./libltdl does not exist
 done
Running libtoolize (GNU libtool) 1.4.3... done
Running autoconf (GNU Autoconf) 2.57... done

I think you need quotes around the -I option to bootstrap.sh as above
(contrary to your commit message).  Otherwise, the $1 in bootstrap.sh will
just catch the -I and miss the rest.

rm -rf /usr/local/plplot_at

./configure --prefix=/usr/local/plplot_at --disable-tcl --disable-itcl \
--disable-python --enable-dyndrivers --with-double > & configure.out

make >& make.out
make install >& make_install.out

All the *.out files looked fine.

cd /usr/local/plplot_at/lib/plplot5.2.0/examples
cd c ; make ; cd c++ ; make ; cd f77 ; make ; cd ..
./plplot-test.sh
Plplot library version: 5.2.0
Opened x01c.ps
Opened x02c.ps
Opened x03c.ps
Opened x04c.ps
Opened x05c.ps
Opened x06c.ps
Opened x07c.ps
Opened x08c.ps
Opened x09c.ps
Opened x10c.ps
Opened x11c.ps
Opened x12c.ps
Opened x13c.ps
Opened x15c.ps
Opened x16c.ps
Opened x18c.ps
Opened x19c.ps
Opened x01cc.ps
Opened x01f.ps
Opened x02f.ps
Opened x03f.ps
Opened x04f.ps
Opened x05f.ps
Opened x06f.ps
Opened x07f.ps
Opened x08f.ps
Opened x09f.ps
Opened x10f.ps
Opened x11f.ps
Opened x12f.ps
Opened x13f.ps
Opened x16f.ps

All these results are identical with the plplot-5.2.0 results.

Joao, do you confirm this set of options is working for you as well
(after removing all traces of old autotools)?

Next, I will try Joao's set of options starting from fresh checkout.

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
__________________________

Re: [Plplot-devel] New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-05 16:56]:

> If you had different configure options than Joao and me but are too tired
> to re-run the test, could you at least tell us what those configuration
> options are?  I might find they work on my system which would imply the bug
> is configure option dependent and not autotools version dependent.

Just a comment on this:  what makes me think that the problem is related to
the autotools is the original report by Joao:

* João Cardoso <jc...@fe...> [2003-02-05 21:06]:

> | > (gdb) run -dev xwin
> | > Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c
> | > -dev xwin
> | >
> | > Program received signal SIGSEGV, Segmentation fault.
> | > 0x0806a46e in lt_dlsym (handle=0x807b0e0,
> | >     symbol=0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
> | > [...]

The bug has been caused by a call to the function lt_dlsym in ltdl.c, more
precisely when it is called with argument "DEVICE_INFO_pstex".  Of course,
this is related to my last changes in the code.  However, I can hardly see
what I am doing wrong, since I cannot replicate the bug.  I tend to believe
that it is related to version problems in the Autotools.  

That said, I really hope that this is a configuration option problem, which
would be easier to fix...

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-05 16:56]:

> If you had different configure options than Joao and me but are too tired
> to re-run the test, could you at least tell us what those configuration
> options are?  I might find they work on my system which would imply the bug
> is configure option dependent and not autotools version dependent.


Here is exactly what I am doing.

    $ rm -rf plplot
    $ cvs -d rla...@cv...:/cvsroot/plplot co plplot
    $ cd plplot
    $ ./bootstrap.sh
    $ destdir=/var/tmp/plplot
    $ ./configure  --prefix=$destdir --disable-tcl --disable-itcl \
                   --disable-python --enable-dyndrivers --with-double
    $ rm -rf $destdir
    $ make install
    $ cd examples/c
    $ make x01c
    $ ./x01c -dev xwin

All the C demos compile and work fine here.

I am now using Libtool 1.4.3 from Debian unstable.  Please noticed that I had
to make changes in bootstrap.sh in order to get this version of Libtool
working properly with Autoconf 2.57 and Automake 1.7.2 (see my last cvs
commit).

If you guys cannot replicate my successful build with the latest version of
bootstrap.sh, I will be completely puzzled.

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Thu, 6 Feb 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-02-05 15:18]:
>
> > You didn't say so, but I presume you configured with exactly same options
> > and have latest stable autotools like Joao and me (not Debian ones).
>
> I have :
>
>     $ ./bootstrap.sh
>     Running aclocal (GNU automake) 1.7.2... done
>     Running libtoolize (GNU libtool) 1.4.2a... done
>     Running autoheader (GNU Autoconf) 2.57... done
>     Running automake (GNU automake) 1.7.2... done
>     Running autoconf (GNU Autoconf) 2.57... done

[then got diverted into version stuff which might be relevant and forgot to
mention the configure options].

If you had different configure options than Joao and me but are too tired
to re-run the test, could you at least tell us what those configuration
options are?  I might find they work on my system which would imply the bug
is configure option dependent and not autotools version dependent.

Joao's further comment about his quite different gcc version seems to take
that version dependence out of contention.

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
__________________________

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

On Wednesday 05 February 2003 23:21, Rafael Laboissiere wrote:
> * Alan W. Irwin <ir...@be...> [2003-02-05 15:18]:
> > You didn't say so, but I presume you configured with exactly same opt=
ions
> > and have latest stable autotools like Joao and me (not Debian ones).
>
> I have :
>
>     $ ./bootstrap.sh
>     Running aclocal (GNU automake) 1.7.2... done
>     Running libtoolize (GNU libtool) 1.4.2a... done
>     Running autoheader (GNU Autoconf) 2.57... done
>     Running automake (GNU automake) 1.7.2... done
>     Running autoconf (GNU Autoconf) 2.57... done
>
> I am not using the latest version of libtool (1.4.3).

I noticed that "file x01c" in the build tree reports an executable  ELF, =
not a=20
script file as is usual with libtool. That's why I make x01c in the insta=
ll=20
directory, but I still get an executable!

>  That may explain the
> difference.  I will try to use 1.4.3, but that is not going to be befor=
e
> this weekend (I have two busy days before me).
>
> > Or maybe it is gcc version?
> >
> > I have Debian woody
> >
> > Version: 2:2.95.4-14

mine is gcc-3.2

>
> I have here:
>
>   Version: 2:2.95.4-17

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-05 15:18]:

> You didn't say so, but I presume you configured with exactly same options
> and have latest stable autotools like Joao and me (not Debian ones).

I have :

    $ ./bootstrap.sh 
    Running aclocal (GNU automake) 1.7.2... done
    Running libtoolize (GNU libtool) 1.4.2a... done
    Running autoheader (GNU Autoconf) 2.57... done
    Running automake (GNU automake) 1.7.2... done
    Running autoconf (GNU Autoconf) 2.57... done

I am not using the latest version of libtool (1.4.3).  That may explain the
difference.  I will try to use 1.4.3, but that is not going to be before
this weekend (I have two busy days before me).    

> Or maybe it is gcc version?
> 
> I have Debian woody
> 
> Version: 2:2.95.4-14

I have here:

  Version: 2:2.95.4-17

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

[Alan W. I. <ir...@be...>]

On Wed, 5 Feb 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-02-05 14:07]:
>
> > Rafael, you should be able to reproduce this bug if you do exactly what I
> > did since we have very similar systems.  Joao's choice of configure options
> > may be important or there may be something left over in your build or
> > install location that makes it work on your system but not on ours. But the
> > fresh checkout and the above rm -rf should take care of that potential
> > difference between us.
>
> I cannot replicate the bug here.  I did exactly what you suggested: fresh
> cvs checkout in a empty dir, ./bootstrap.sh, make, and make install (haveing
> rm -rf the install destination before).  All x??c.c examples compile and
> work perfectly.
>
> I am puzzled.

So am I!

You didn't say so, but I presume you configured with exactly same options
and have latest stable autotools like Joao and me (not Debian ones).

Or maybe it is gcc version?

I have Debian woody

Version: 2:2.95.4-14

If everything is the same between us, then try valgrind on x01c in case
there are memory problems but they just happen not to have any nasty
consequences for your particular machine (often memory management bugs give
different results on different machines because they are history dependent).

If valgrind shows no problems at all, then I am really REALLY puzzled.
Bitrot has set in, its the end of the world as I know it, I am going
crazy....;-)

Or should that be crazier....;-)

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
__________________________

[Plplot-devel] Re: New way of getting device info from dyndrivers

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-05 14:07]:

> Rafael, you should be able to reproduce this bug if you do exactly what I
> did since we have very similar systems.  Joao's choice of configure options
> may be important or there may be something left over in your build or
> install location that makes it work on your system but not on ours. But the
> fresh checkout and the above rm -rf should take care of that potential
> difference between us.

I cannot replicate the bug here.  I did exactly what you suggested: fresh
cvs checkout in a empty dir, ./bootstrap.sh, make, and make install (haveing
rm -rf the install destination before).  All x??c.c examples compile and
work perfectly.

I am puzzled.

-- 
Rafael