You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(14) |
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(16) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(13) |
Feb
(22) |
Mar
(7) |
Apr
(8) |
May
(8) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(31) |
Nov
(23) |
Dec
(3) |
2002 |
Jan
(1) |
Feb
(17) |
Mar
(10) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(21) |
Dec
(20) |
2003 |
Jan
(27) |
Feb
(13) |
Mar
(20) |
Apr
(11) |
May
(12) |
Jun
(7) |
Jul
(16) |
Aug
(21) |
Sep
(9) |
Oct
(28) |
Nov
(24) |
Dec
(30) |
2004 |
Jan
(31) |
Feb
(5) |
Mar
|
Apr
(8) |
May
(12) |
Jun
(7) |
Jul
(13) |
Aug
(12) |
Sep
(2) |
Oct
(14) |
Nov
(42) |
Dec
(14) |
2005 |
Jan
|
Feb
|
Mar
(20) |
Apr
(17) |
May
(9) |
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(17) |
Oct
(14) |
Nov
(9) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(13) |
Apr
(2) |
May
(46) |
Jun
(2) |
Jul
(20) |
Aug
(26) |
Sep
(31) |
Oct
(5) |
Nov
(9) |
Dec
(13) |
2007 |
Jan
(24) |
Feb
(22) |
Mar
(13) |
Apr
(25) |
May
(25) |
Jun
(9) |
Jul
(20) |
Aug
(9) |
Sep
(26) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
2008 |
Jan
(92) |
Feb
(35) |
Mar
(39) |
Apr
(15) |
May
|
Jun
|
Jul
(18) |
Aug
(5) |
Sep
(5) |
Oct
(7) |
Nov
(10) |
Dec
(27) |
2009 |
Jan
(35) |
Feb
(34) |
Mar
(13) |
Apr
(9) |
May
(18) |
Jun
(9) |
Jul
(15) |
Aug
(13) |
Sep
(64) |
Oct
(7) |
Nov
(43) |
Dec
|
2010 |
Jan
(75) |
Feb
(22) |
Mar
(44) |
Apr
(34) |
May
(47) |
Jun
(77) |
Jul
(28) |
Aug
(7) |
Sep
(45) |
Oct
(1) |
Nov
(19) |
Dec
(7) |
2011 |
Jan
(14) |
Feb
|
Mar
(6) |
Apr
(12) |
May
(19) |
Jun
(3) |
Jul
(8) |
Aug
(4) |
Sep
(3) |
Oct
(21) |
Nov
(11) |
Dec
(4) |
2012 |
Jan
(2) |
Feb
(9) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(5) |
Oct
(1) |
Nov
(18) |
Dec
(2) |
2013 |
Jan
(15) |
Feb
(16) |
Mar
(8) |
Apr
(5) |
May
|
Jun
(1) |
Jul
(17) |
Aug
(3) |
Sep
(17) |
Oct
(43) |
Nov
(25) |
Dec
(9) |
2014 |
Jan
(4) |
Feb
(8) |
Mar
(20) |
Apr
(14) |
May
(49) |
Jun
(1) |
Jul
|
Aug
(18) |
Sep
(2) |
Oct
(1) |
Nov
(22) |
Dec
(3) |
2015 |
Jan
(41) |
Feb
(2) |
Mar
(34) |
Apr
(30) |
May
(14) |
Jun
(17) |
Jul
(29) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(7) |
Dec
(4) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(25) |
Oct
(9) |
Nov
(14) |
Dec
(13) |
2017 |
Jan
(11) |
Feb
(8) |
Mar
(12) |
Apr
(4) |
May
(25) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(10) |
Oct
(25) |
Nov
|
Dec
(6) |
2018 |
Jan
(18) |
Feb
(6) |
Mar
(6) |
Apr
(1) |
May
(7) |
Jun
(13) |
Jul
(8) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
(17) |
Dec
(3) |
2019 |
Jan
(11) |
Feb
(4) |
Mar
(13) |
Apr
(19) |
May
(1) |
Jun
(2) |
Jul
(8) |
Aug
(4) |
Sep
(32) |
Oct
(51) |
Nov
(1) |
Dec
(9) |
2020 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
|
2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alan W. I. <ai...@us...> - 2003-10-16 22:21:44
|
On 2003-10-16 15:43-0500 Herng-Jeng Jou wrote: > Hi Alan, > Thanks for the useful explanation. > I did what you explained with the CVS 20031004 by: > $ ./configure --prefix=/usr/local/plplot_at --disable-dyndrivers > --with-double > $ make > $ su > # make install > # exit > $ cd example/c++ > $ /usr/local/plplot_at/bin/plplot_libtool --mode=link g++ -all-static > x01.cc \ > -I/usr/local/plplot_at/include/plplot -L/usr/local/plplot_at/lib \ > -lplplotcxxd -o x01 -ldl > on my system, it complaints that -ltk8.3 cannot be found. I think it is > because > I only have /usr/lib/libtk8.3.so, no .a in it. > Jou That kills your dream of having an all-static result for your present system. But if your system is Linux (I have forgotten) it is a simple matter to install the static versions of all libraries. They are usually in the development rpm. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Herng-Jeng J. <hj...@qu...> - 2003-10-16 20:46:16
|
<html> <font size=3>Hi Alan,<br> Thanks for the useful explanation.<br> I did what you explained with the CVS 20031004 by:<br> $ ./configure --prefix=/usr/local/plplot_at --disable-dyndrivers --with-double<br> $ make<br> $ su<br> # make install <br> # exit<br> $ cd example/c++<br> $ /usr/local/plplot_at/bin/plplot_libtool --mode=link g++ -all-static x01.cc \<br> -I/usr/local/plplot_at/include/plplot -L/usr/local/plplot_at/lib \<br> -lplplotcxxd -o x01 -ldl<br> on my system, it complaints that -ltk8.3 cannot be found. I think it is because<br> I only have /usr/lib/libtk8.3.so, no .a in it.<br> Jou<br> <br> At 11:56 AM 10/15/2003 -0700, Alan W. Irwin wrote:<br> <blockquote type=cite cite>On 2003-10-15 09:37-0500 Herng-Jeng Jou wrote:<br> <br> > After I install PLplot into "/usr/local/plplot" directory,<br> > then I was trying to compile a standalone x01 without dynamic linkage at<br> > all to PLplot, and<br> > this is what I did:<br> > $ g++ -I/usr/local/plplot/include/plplot -c x01.cc<br> > $ g++ -g -O2 -o x01 x01.o /usr/local/plplot/lib/libplplotcxxd.a<br> > /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so<br> > /usr/local/plplot/lib/libcsirocsa.a -ldl<br> <br> You should use plplot_libtool to solve the problem of making statically<br> linked versions of executables.<br> <br> Here is what to do:<br> <br> Adjust the line below for your prefix, but if I build<br> plplot-5.2.1.cvs.20031004 using<br> <br> --prefix=/usr/local/plplot_at --disable-dyndrivers<br> <br> Note the --disable-dyndrivers is essential because the combination of static<br> libraries (what you are ultimately trying to use) and dyndrivers does not<br> currently work.<br> <br> plplot_libtool --mode=link g++ -all-static x01.cc \<br> -I/usr/local/plplot_at/include/plplot -L/usr/local/plplot_at/lib \<br> -lplplotcxxd -o x01 -ldl<br> <br> then I get good results.<br> <br> Herng-Jeng and Andrew, will you please confirm this also works well on your<br> systems?<br> <br> Note the resulting executable is statically linked:<br> <br> file x01<br> x01: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically<br> linked, not stripped<br> <br> Also, the size of the executable is enormous<br> <br> ls -l x01<br> -rwxr-xr-x 1 software software 4760851 Oct 15 11:36 x01*<br> <br> But ./x01 -dev xwin, for example, works fine.<br> <br> I tried the same thing in the c directory, and again no problems.<br> <br> Also, I tried ordinary builds using make (which invokes plplot_libtool<br> without the -all-static and -ldl options) and they worked fine as well.<br> <br> So plplot_libtool is your friend for sorting out various linking cases.<br> (Rafael is working on a replacement to plplot_libtool which should be<br> able to do the same thing in a simpler way, but until that works,<br> use plplot_libtool.)<br> <br> What is going on here is that by default, both dynamic and static versions<br> of the plplot library are built. And the plplot_libtool -all-static flag<br> (see info libtool for documentation on how to invoke libtool, and therefore<br> its locally configured copy for your system, plplot_libtool) forces use of<br> the static libraries. On my system, the above plplot_libtool command<br> generates the following good compile/build commmand and executes it:<br> <br> g++ -static x01.cc -I/usr/local/plplot_at/include/plplot -o x01<br> -L/usr/local/plplot_at/lib /usr/local/plplot_at/lib/libplplotcxxd.a<br> /usr/local/plplot_at/lib/libplplotd.a /usr/local/plplot_at/lib/libcsirocsa.a<br> /usr/local/plplot_at/lib/libcsironn.a -lqhull -lcd -lgd -lpng<br> /usr/lib/libjpeg.a -lz -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3<br> /usr/lib/libfreetype.a -L/usr/X11R6/lib -lX11 -ldl<br> <br> So you could adjust your own g++ invocation to mimic this, but I think it is<br> much better to use plplot_libtool directly.<br> <br> BTW, the reason I knew what to do with plplot_libtool was I pretty much<br> (except for the -all-static option and -ldl on the end) followed what was<br> done for the examples to build them. I have already discussed why<br> -all-static is necessary. I found that the -ldl flag was necessary for the<br> --all-static case because /usr/lib/libtcl8.3.a refers to dlopen and friends,<br> and you have to resolve those reference with an explicit -ldl option.<br> <br> Alan<br> __________________________<br> Alan W. Irwin<br> email: ir...@be...<br> phone: 250-727-2902<br> <br> Astronomical research affiliation with Department of Physics and Astronomy,<br> University of Victoria (astrowww.phys.uvic.ca).<br> <br> Programming affiliations with the PLplot scientific plotting software<br> package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the<br> Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project<br> (lbproject.sf.net).<br> __________________________<br> <br> Linux-powered Science<br> __________________________<br> <br> <br> -------------------------------------------------------<br> This SF.net email is sponsored by: SF.net Giveback Program.<br> SourceForge.net hosts over 70,000 Open Source Projects.<br> See the people who have HELPED US provide better services:<br> Click here: <a href="http://sourceforge.net/supporters.php" eudora="autourl">http://sourceforge.net/supporters.php</a><br> _______________________________________________<br> Plplot-general mailing list<br> Plp...@li...<br> <a href="https://lists.sourceforge.net/lists/listinfo/plplot-general" eudora="autourl">https://lists.sourceforge.net/lists/listinfo/plplot-general</a> </font></blockquote><br> </html> |
From: Alan W. I. <ai...@us...> - 2003-10-15 19:01:52
|
On 2003-10-15 17:27+0100 Jo=E3o Cardoso wrote: > Of course we don't expect users to do what Herng-Jeng Jou did, but users > migh want to generate a static executable to, say, sent id to a friend? Yes, it is certainly worthwhile to be able to link both with the shared and static versions of libplplot. These options are provided by libtool (and therefore plplot_libtool). More details in a post I just sent off to plplot-general to answer Herng-Jeng directly. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ai...@us...> - 2003-10-15 18:56:51
|
On 2003-10-15 09:37-0500 Herng-Jeng Jou wrote: > After I install PLplot into "/usr/local/plplot" directory, > then I was trying to compile a standalone x01 without dynamic linkage at > all to PLplot, and > this is what I did: > $ g++ -I/usr/local/plplot/include/plplot -c x01.cc > $ g++ -g -O2 -o x01 x01.o /usr/local/plplot/lib/libplplotcxxd.a > /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so > /usr/local/plplot/lib/libcsirocsa.a -ldl You should use plplot_libtool to solve the problem of making statically linked versions of executables. Here is what to do: Adjust the line below for your prefix, but if I build plplot-5.2.1.cvs.20031004 using --prefix=/usr/local/plplot_at --disable-dyndrivers Note the --disable-dyndrivers is essential because the combination of static libraries (what you are ultimately trying to use) and dyndrivers does not currently work. plplot_libtool --mode=link g++ -all-static x01.cc \ -I/usr/local/plplot_at/include/plplot -L/usr/local/plplot_at/lib \ -lplplotcxxd -o x01 -ldl then I get good results. Herng-Jeng and Andrew, will you please confirm this also works well on your systems? Note the resulting executable is statically linked: file x01 x01: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped Also, the size of the executable is enormous ls -l x01 -rwxr-xr-x 1 software software 4760851 Oct 15 11:36 x01* But ./x01 -dev xwin, for example, works fine. I tried the same thing in the c directory, and again no problems. Also, I tried ordinary builds using make (which invokes plplot_libtool without the -all-static and -ldl options) and they worked fine as well. So plplot_libtool is your friend for sorting out various linking cases. (Rafael is working on a replacement to plplot_libtool which should be able to do the same thing in a simpler way, but until that works, use plplot_libtool.) What is going on here is that by default, both dynamic and static versions of the plplot library are built. And the plplot_libtool -all-static flag (see info libtool for documentation on how to invoke libtool, and therefore its locally configured copy for your system, plplot_libtool) forces use of the static libraries. On my system, the above plplot_libtool command generates the following good compile/build commmand and executes it: g++ -static x01.cc -I/usr/local/plplot_at/include/plplot -o x01 -L/usr/local/plplot_at/lib /usr/local/plplot_at/lib/libplplotcxxd.a /usr/local/plplot_at/lib/libplplotd.a /usr/local/plplot_at/lib/libcsirocsa.a /usr/local/plplot_at/lib/libcsironn.a -lqhull -lcd -lgd -lpng /usr/lib/libjpeg.a -lz -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 /usr/lib/libfreetype.a -L/usr/X11R6/lib -lX11 -ldl So you could adjust your own g++ invocation to mimic this, but I think it is much better to use plplot_libtool directly. BTW, the reason I knew what to do with plplot_libtool was I pretty much (except for the -all-static option and -ldl on the end) followed what was done for the examples to build them. I have already discussed why -all-static is necessary. I found that the -ldl flag was necessary for the --all-static case because /usr/lib/libtcl8.3.a refers to dlopen and friends, and you have to resolve those reference with an explicit -ldl option. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-10-15 16:29:28
|
On Wednesday 15 October 2003 15:37, Herng-Jeng Jou wrote: | Thanks Andrew for your quick response. | Since I don't quite understand the build process, so it is very | likely that I screwed up. | This is how x01 was built with the supplied Makefile in examples/c++ | directory: $ make x01 | /bin/sh ../../libtool --mode=link g++ -g -O2 -o x01 x01.o | ../../bindings/c++/libplplotcxxd.la | $ g++ -g -O2 -o .libs/x01 x01.o | ../../bindings/c++/.libs/libplplotcxxd.so | /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/src/.libs/libplplotd.so | /usr/lib/libfreetype.so | /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/lib/csa/.libs/libcsiroc |sa.so -ldl -Wl,--rpath -Wl,/usr/local/plplot/lib | creating x01 | | and that makes a executable .libs/x01 and x01 script and it works | fine. | | After I install PLplot into "/usr/local/plplot" directory, | then I was trying to compile a standalone x01 without dynamic linkage | at all to PLplot, and | this is what I did: | $ g++ -I/usr/local/plplot/include/plplot -c x01.cc | $ g++ -g -O2 -o x01 x01.o /usr/local/plplot/lib/libplplotcxxd.a | /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so | /usr/local/plplot/lib/libcsirocsa.a -ldl | | $ ldd x01 | libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40023000) | libdl.so.2 => /lib/libdl.so.2 (0x40063000) | libstdc++-libc6.2-2.so.3 => | /usr/lib/libstdc++-libc6.2-2.so.3 (0x40066000) | libm.so.6 => /lib/i686/libm.so.6 (0x400a9000) | libc.so.6 => /lib/i686/libc.so.6 (0x42000000) | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) | | looks like this x01 executable has correct linkage. But when I run | it, I got a empty | page with it. I kind-of confirm this with current CVS and x01c.c. Of course we don't expect users to do what Herng-Jeng Jou did, but users migh want to generate a static executable to, say, sent id to a friend? And this raises another shared/static question: if plplot_libtool or pkg_config don't support both kinds of linking, we should disable static if shared is allowed. Or I'm missing something? Joao |
From: Andrew R. <an...@co...> - 2003-10-15 16:27:47
|
OK. I've reproduced the problem with my setup. Firstly it's not a C++ problem - the same thing occurs with the C drivers. I wondered if it is related to the dynamic drivers however the drivers appear to load ok. It also occurs with postscript and xwin drivers for me so it's not specific to a driver. Running the examples with the -debug option doesn't reveal any differences between the dynamic and static cases. In the case of the postscript driver the statically linked output is not empty - there are a whole series of drawing commands in the output file, however the coordinates are all the same. Maybe one of the developers can throw some light on this. Andrew P.S. Given that you have (I presume) compiled with dynamic drivers is there any particular reason you want to statically link in the plplot library? To use the program on another machine you would also need to distrubute the drivers in plplot/lib/plplot/driversd/. On Wed, Oct 15, 2003 at 09:37:29AM -0500, Herng-Jeng Jou wrote: > Thanks Andrew for your quick response. > Since I don't quite understand the build process, so it is very likely that > directory: > $ make x01 > /bin/sh ../../libtool --mode=link g++ -g -O2 -o x01 x01.o > ../../bindings/c++/libplplotcxxd.la > $ g++ -g -O2 -o .libs/x01 x01.o ../../bindings/c++/.libs/libplplotcxxd.so > /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/src/.libs/libplplotd.so > /usr/lib/libfreetype.so > /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/lib/csa/.libs/libcsirocsa.so > -ldl -Wl,--rpath -Wl,/usr/local/plplot/lib > creating x01 > > and that makes a executable .libs/x01 and x01 script and it works fine. > > After I install PLplot into "/usr/local/plplot" directory, > then I was trying to compile a standalone x01 without dynamic linkage at > all to PLplot, and > this is what I did: > $ g++ -I/usr/local/plplot/include/plplot -c x01.cc > $ g++ -g -O2 -o x01 x01.o /usr/local/plplot/lib/libplplotcxxd.a > /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so > /usr/local/plplot/lib/libcsirocsa.a -ldl > > $ ldd x01 > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40023000) > libdl.so.2 => /lib/libdl.so.2 (0x40063000) > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0x40066000) > libm.so.6 => /lib/i686/libm.so.6 (0x400a9000) > libc.so.6 => /lib/i686/libc.so.6 (0x42000000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > looks like this x01 executable has correct linkage. But when I run it, I > got a empty > page with it. Same problem as x02 if I try compiling this way. > All of these (lib,example source, etc) were done using CVS 20031004 > snapshot. > The library was configured with --prefix==/usr/local/plplot --with-double > flag. > Thanks for your help. > Jou > > At 03:02 PM 10/15/2003 +0100, Andrew Ross wrote: > > >Hi Jou, > > > >How exactly are you compiling the examples statically? Do you mean > >that you are compiling the whole library statically? > > > >There have been some API changes in the C++ bindings so you are now > >required to call plstream::init() explicitly. Is it possible that you > >are linking against an old version of the library which might explain > >your problem? > > > >Do you get the same problems with all the C++ examples? > > > >Cheers > > > >Andrew > > > >On Wed, Oct 15, 2003 at 08:38:54AM -0500, Herng-Jeng Jou wrote: > >> Hi, > >> I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. > >> The x01.cc example works fine as compiled with dynamic linkage. When I > >tried > >> to link it statically, the executable runs with an empty plotting window > >> (black > >> background) and with no plot in it. > >> Jou > >> > >> ======================================= > >> Herng-Jeng Jou > >> QuesTek Innovations, LLC > >> 1820 Ridge Avenue > >> Evanston, IL 60201 > >> (Tel) 847.425.8221 > >> (Fax) 847.328.5855 > >> hj...@qu... > >> > >> > > > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: SF.net Giveback Program. > >> SourceForge.net hosts over 70,000 Open Source Projects. > >> See the people who have HELPED US provide better services: > >> Click here: http://sourceforge.net/supporters.php > >> _______________________________________________ > >> Plplot-general mailing list > >> Plp...@li... > >> https://lists.sourceforge.net/lists/listinfo/plplot-general > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >SourceForge.net hosts over 70,000 Open Source Projects. > >See the people who have HELPED US provide better services: > >Click here: http://sourceforge.net/supporters.php > >_______________________________________________ > >Plplot-general mailing list > >Plp...@li... > >https://lists.sourceforge.net/lists/listinfo/plplot-general > > ======================================= > Herng-Jeng Jou > QuesTek Innovations, LLC > 1820 Ridge Avenue > Evanston, IL 60201 > (Tel) 847.425.8221 > (Fax) 847.328.5855 > hj...@qu... |
From: Andrew R. <an...@co...> - 2003-10-15 16:05:02
|
Hi Jou, I'm afraid there is no GUI option in C++ to save the current plot like there is with the tk examples. You can do it in your own programs though. Look at example x20 which allows you to save a plot by replicating a stream using cpstrm, changing the device and then replotting. This should do what you want. Same goes for C. Andrew On Wed, Oct 15, 2003 at 10:39:51AM -0500, Herng-Jeng Jou wrote: > Hi Andrew, > > I have another question in the C++ binding, hope you don't mind. > Is it possible to save the output to a file while the plot is currently > being > viewed? I think it is possible as that has been achieved in the tk driver. > But I could not figure out how to do that in C++/PLplot. > Can you help? > Thanks, > > Jou > > At 03:02 PM 10/15/2003 +0100, Andrew Ross wrote: > > >Hi Jou, > > > >How exactly are you compiling the examples statically? Do you mean > >that you are compiling the whole library statically? > > > >There have been some API changes in the C++ bindings so you are now > >required to call plstream::init() explicitly. Is it possible that you > >are linking against an old version of the library which might explain > >your problem? > > > >Do you get the same problems with all the C++ examples? > > > >Cheers > > > >Andrew > > > >On Wed, Oct 15, 2003 at 08:38:54AM -0500, Herng-Jeng Jou wrote: > >> Hi, > >> I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. > >> The x01.cc example works fine as compiled with dynamic linkage. When I > >tried > >> to link it statically, the executable runs with an empty plotting window > >> (black > >> background) and with no plot in it. > >> Jou > >> > >> ======================================= > >> Herng-Jeng Jou > >> QuesTek Innovations, LLC > >> 1820 Ridge Avenue > >> Evanston, IL 60201 > >> (Tel) 847.425.8221 > >> (Fax) 847.328.5855 > >> hj...@qu... > >> > >> > > > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: SF.net Giveback Program. > >> SourceForge.net hosts over 70,000 Open Source Projects. > >> See the people who have HELPED US provide better services: > >> Click here: http://sourceforge.net/supporters.php > >> _______________________________________________ > >> Plplot-general mailing list > >> Plp...@li... > >> https://lists.sourceforge.net/lists/listinfo/plplot-general > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >SourceForge.net hosts over 70,000 Open Source Projects. > >See the people who have HELPED US provide better services: > >Click here: http://sourceforge.net/supporters.php > >_______________________________________________ > >Plplot-general mailing list > >Plp...@li... > >https://lists.sourceforge.net/lists/listinfo/plplot-general > > ======================================= > Herng-Jeng Jou > QuesTek Innovations, LLC > 1820 Ridge Avenue > Evanston, IL 60201 > (Tel) 847.425.8221 > (Fax) 847.328.5855 > hj...@qu... |
From: Herng-Jeng J. <hj...@qu...> - 2003-10-15 15:40:38
|
Hi Andrew, I have another question in the C++ binding, hope you don't mind. Is it possible to save the output to a file while the plot is currently being viewed? I think it is possible as that has been achieved in the tk driver. But I could not figure out how to do that in C++/PLplot. Can you help? Thanks, Jou At 03:02 PM 10/15/2003 +0100, Andrew Ross wrote: >Hi Jou, > >How exactly are you compiling the examples statically? Do you mean >that you are compiling the whole library statically? > >There have been some API changes in the C++ bindings so you are now >required to call plstream::init() explicitly. Is it possible that you >are linking against an old version of the library which might explain >your problem? > >Do you get the same problems with all the C++ examples? > >Cheers > >Andrew > >On Wed, Oct 15, 2003 at 08:38:54AM -0500, Herng-Jeng Jou wrote: > > Hi, > > I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. > > The x01.cc example works fine as compiled with dynamic linkage. When I > tried > > to link it statically, the executable runs with an empty plotting window > > (black > > background) and with no plot in it. > > Jou > > > > ======================================= > > Herng-Jeng Jou > > QuesTek Innovations, LLC > > 1820 Ridge Avenue > > Evanston, IL 60201 > > (Tel) 847.425.8221 > > (Fax) 847.328.5855 > > hj...@qu... > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. > > See the people who have HELPED US provide better services: > > Click here: http://sourceforge.net/supporters.php > > _______________________________________________ > > Plplot-general mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-general > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >SourceForge.net hosts over 70,000 Open Source Projects. >See the people who have HELPED US provide better services: >Click here: http://sourceforge.net/supporters.php >_______________________________________________ >Plplot-general mailing list >Plp...@li... >https://lists.sourceforge.net/lists/listinfo/plplot-general ======================================= Herng-Jeng Jou QuesTek Innovations, LLC 1820 Ridge Avenue Evanston, IL 60201 (Tel) 847.425.8221 (Fax) 847.328.5855 hj...@qu... |
From: Herng-Jeng J. <hj...@qu...> - 2003-10-15 14:38:11
|
Thanks Andrew for your quick response. Since I don't quite understand the build process, so it is very likely that I screwed up. This is how x01 was built with the supplied Makefile in examples/c++ directory: $ make x01 /bin/sh ../../libtool --mode=link g++ -g -O2 -o x01 x01.o ../../bindings/c++/libplplotcxxd.la $ g++ -g -O2 -o .libs/x01 x01.o ../../bindings/c++/.libs/libplplotcxxd.so /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/src/.libs/libplplotd.so /usr/lib/libfreetype.so /afs/hjjou/archives/plplot-5.2.1.cvs.20031004/lib/csa/.libs/libcsirocsa.so -ldl -Wl,--rpath -Wl,/usr/local/plplot/lib creating x01 and that makes a executable .libs/x01 and x01 script and it works fine. After I install PLplot into "/usr/local/plplot" directory, then I was trying to compile a standalone x01 without dynamic linkage at all to PLplot, and this is what I did: $ g++ -I/usr/local/plplot/include/plplot -c x01.cc $ g++ -g -O2 -o x01 x01.o /usr/local/plplot/lib/libplplotcxxd.a /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so /usr/local/plplot/lib/libcsirocsa.a -ldl $ ldd x01 libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40023000) libdl.so.2 => /lib/libdl.so.2 (0x40063000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40066000) libm.so.6 => /lib/i686/libm.so.6 (0x400a9000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) looks like this x01 executable has correct linkage. But when I run it, I got a empty page with it. Same problem as x02 if I try compiling this way. All of these (lib,example source, etc) were done using CVS 20031004 snapshot. The library was configured with --prefix==/usr/local/plplot --with-double flag. Thanks for your help. Jou At 03:02 PM 10/15/2003 +0100, Andrew Ross wrote: >Hi Jou, > >How exactly are you compiling the examples statically? Do you mean >that you are compiling the whole library statically? > >There have been some API changes in the C++ bindings so you are now >required to call plstream::init() explicitly. Is it possible that you >are linking against an old version of the library which might explain >your problem? > >Do you get the same problems with all the C++ examples? > >Cheers > >Andrew > >On Wed, Oct 15, 2003 at 08:38:54AM -0500, Herng-Jeng Jou wrote: > > Hi, > > I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. > > The x01.cc example works fine as compiled with dynamic linkage. When I > tried > > to link it statically, the executable runs with an empty plotting window > > (black > > background) and with no plot in it. > > Jou > > > > ======================================= > > Herng-Jeng Jou > > QuesTek Innovations, LLC > > 1820 Ridge Avenue > > Evanston, IL 60201 > > (Tel) 847.425.8221 > > (Fax) 847.328.5855 > > hj...@qu... > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. > > See the people who have HELPED US provide better services: > > Click here: http://sourceforge.net/supporters.php > > _______________________________________________ > > Plplot-general mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-general > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >SourceForge.net hosts over 70,000 Open Source Projects. >See the people who have HELPED US provide better services: >Click here: http://sourceforge.net/supporters.php >_______________________________________________ >Plplot-general mailing list >Plp...@li... >https://lists.sourceforge.net/lists/listinfo/plplot-general ======================================= Herng-Jeng Jou QuesTek Innovations, LLC 1820 Ridge Avenue Evanston, IL 60201 (Tel) 847.425.8221 (Fax) 847.328.5855 hj...@qu... |
From: Andrew R. <an...@co...> - 2003-10-15 14:03:00
|
Hi Jou, How exactly are you compiling the examples statically? Do you mean that you are compiling the whole library statically? There have been some API changes in the C++ bindings so you are now required to call plstream::init() explicitly. Is it possible that you are linking against an old version of the library which might explain your problem? Do you get the same problems with all the C++ examples? Cheers Andrew On Wed, Oct 15, 2003 at 08:38:54AM -0500, Herng-Jeng Jou wrote: > Hi, > I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. > The x01.cc example works fine as compiled with dynamic linkage. When I tried > to link it statically, the executable runs with an empty plotting window > (black > background) and with no plot in it. > Jou > > ======================================= > Herng-Jeng Jou > QuesTek Innovations, LLC > 1820 Ridge Avenue > Evanston, IL 60201 > (Tel) 847.425.8221 > (Fax) 847.328.5855 > hj...@qu... > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Herng-Jeng J. <hj...@qu...> - 2003-10-15 13:39:33
|
Hi, I compiled PLplot CVS 20031004 ok on RedHat Linux 7.3 with gcc/g++ 2.96. The x01.cc example works fine as compiled with dynamic linkage. When I tried to link it statically, the executable runs with an empty plotting window (black background) and with no plot in it. Jou ======================================= Herng-Jeng Jou QuesTek Innovations, LLC 1820 Ridge Avenue Evanston, IL 60201 (Tel) 847.425.8221 (Fax) 847.328.5855 hj...@qu... |
From: Rafael L. <ra...@de...> - 2003-10-09 22:11:32
|
The latest version of the PLplot (http://plplot.sf.net) packages available in Debian unstable has been back-ported to the Debian woody distribution. The apt-getable repository is at the following URL: http://people.debian.org/~rafael/plplot-woody Although these are not official packages, bug reports can be filed using the Debian Bug Tracking System. Enjoy, -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-10-07 16:24:07
|
* João Cardoso <jc...@fe...> [2003-10-07 16:31]: > I think it's better, although it's not nice. > Perhaps changing the message to > > configure: WARNING: no suitable Python interpreter found, please > ignore the next 6 messages It is not possible, since this message is buried into the AM_PATH_PYTHON macro, which is automatically generated by aclocal. I am going to commit the changes, anyway. Perhaps we find a better solution in the future. -- Rafael |
From: <jc...@fe...> - 2003-10-07 15:32:34
|
On Tuesday 07 October 2003 15:35, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-10-06 16:41]: | > Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, | > | > With a plain ./configure --prefix=3D... | > | > checking for sin in -lm... yes | > checking for a Python interpreter with version >=3D 1.5... configure: | > error: no suitable Python interpreter found | > | > and configure stops. Shouldn't it continue, with python disabled? | | Yes, this would be the preferable situation, but it is not completely | under our control, because the python version checks are done in | macro AM_PATH_PYTHON, included in aclocal.m4 by the aclocal command.=20 | We are not allowed to change this file, since it is automatically | generated. | | There is a workaround, though, by redefining temporarily the | AC_MSG_ERROR macro around the call to AM_PATH_PYTHON. The m4 trick | is like this: | | pushdef([AC_MSG_ERROR],defn([AC_MSG_WARN])) | AM_PATH_PYTHON(1.5) | popdef([AC_MSG_ERROR]) | | Then, instead of stopping when python is not available, configure | continues but barks like this: | | [...] | checking for sin in -lm... yes | checking for a Python interpreter with version >=3D 1.5... | configure: WARNING: no suitable Python interpreter found | | checking for :... no | checking for : version... ./configure: line 1: -c: command not | found | | checking for : platform... ./configure: line 1: -c: command not | found | | checking for : script directory... | ${prefix}/lib/python/site-packages checking for : extension module | directory... | ${exec_prefix}/lib/python/site-packages | "Uhhh." | warning: Java Native Interface include file not found | checking for main in -lgd... yes | [...] | | | What do you think? Should I commit this change? I think it's better, although it's not nice. Perhaps changing the message to=20 configure: WARNING: no suitable Python interpreter found, please ignore the next 6 messages ? Joao |
From: Rafael L. <lab...@ps...> - 2003-10-07 14:35:29
|
* João Cardoso <jc...@fe...> [2003-10-06 16:41]: > Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, > > With a plain ./configure --prefix=... > > checking for sin in -lm... yes > checking for a Python interpreter with version >= 1.5... configure: > error: no suitable Python interpreter found > > and configure stops. Shouldn't it continue, with python disabled? Yes, this would be the preferable situation, but it is not completely under our control, because the python version checks are done in macro AM_PATH_PYTHON, included in aclocal.m4 by the aclocal command. We are not allowed to change this file, since it is automatically generated. There is a workaround, though, by redefining temporarily the AC_MSG_ERROR macro around the call to AM_PATH_PYTHON. The m4 trick is like this: pushdef([AC_MSG_ERROR],defn([AC_MSG_WARN])) AM_PATH_PYTHON(1.5) popdef([AC_MSG_ERROR]) Then, instead of stopping when python is not available, configure continues but barks like this: [...] checking for sin in -lm... yes checking for a Python interpreter with version >= 1.5... configure: WARNING: no suitable Python interpreter found : checking for :... no checking for : version... ./configure: line 1: -c: command not found checking for : platform... ./configure: line 1: -c: command not found checking for : script directory... ${prefix}/lib/python/site-packages checking for : extension module directory... ${exec_prefix}/lib/python/site-packages "Uhhh." warning: Java Native Interface include file not found checking for main in -lgd... yes [...] What do you think? Should I commit this change? -- Rafael |
From: <jc...@fe...> - 2003-10-06 15:42:30
|
On Sunday 05 October 2003 01:02, Rafael Laboissiere wrote: | A new CVS snapshot distribution tarball for PLplot is available at | the usual place: | | http://people.debian.org/~rafael/plplot.html | | You will find below the changelog of the recent changes in CVS. | | Please, test and report. Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, With a plain ./configure --prefix=... checking for sin in -lm... yes checking for a Python interpreter with version >= 1.5... configure: error: no suitable Python interpreter found and configure stops. Shouldn't it continue, with python disabled? -After disabling it, a sucessefull make/make install (with only the C, F77 and C++ bindings) make check (in the build tree) fails with x01.cc: In member function `void x01::plot1(int)': x01.cc:276: `usleep' undeclared (first use this function) -and also at x17.cc: In constructor `x17::x17(int, char**)': x17.cc:148: `usleep' undeclared (first use this function) the corresponding C demos compile/work ok. -Some fortran demos are not similar to the C demos. Besides, - in demo 4 the "-20 dB/ecade" message is misplaced and only the first page is plotted. - demo 8/11 don't show up the plot and says: "plot3dc: Y array must be strictly increasing, aborting operation" -The x20 c++ demo fails with "No such file - aborting"; after copying lena.pgm to the c++ examples dir it workedl) -The x21 c++ demos fails with "Floating point exception"; adding -mieee to the gcc command line solves the problem. The -mieee gcc option is OS dependent, and is set in sysloc.in (I think) Sorry I can't give more help now, Joao |
From: Rafael L. <lab...@ps...> - 2003-10-05 00:03:26
|
A new CVS snapshot distribution tarball for PLplot is available at the usual place: http://people.debian.org/~rafael/plplot.html You will find below the changelog of the recent changes in CVS. Please, test and report. -- Rafael ============== Changelog ============== 2003-10-05 01:42 rlaboiss * lib/csa/Makefile.am: Removed csa_internal.h from EXTRA_DIST. 2003-10-04 23:05 airwin * drivers/README.drivers: This is the long-promised update of this basic documentation file for writing device drivers for PLplot. 2003-10-04 22:29 jcard * lib/nn/Makefile.am, lib/nn/delaunay.c, lib/nn/delaunay.h, lib/nn/hash.c, lib/nn/hash.h, lib/nn/linear.c, lib/nn/lpi.c, lib/nn/nan.h, lib/nn/nn.h, lib/nn/nnai.c, lib/nn/nncommon.c, lib/nn/nnpi.c, lib/nn/version.h, src/plgridd.c: Update to nn version 1.38 2003-10-04 22:25 jcard * lib/csa/csa_internal.h: Not needed in csa version 0.22 2003-10-04 22:24 jcard * lib/csa/: csa.c, csa.h, nan.h, version.h: Update to csa version 0.22 2003-10-04 19:53 airwin * examples/: c/Makefile.examples.in, c++/Makefile.examples.in, f77/Makefile.examples.in, tk/Makefile.examples.in: Put in EXEEXT (executable extension) support for those platforms like Cygwin that require it. Also, make the clean and all targets identical. 2003-10-04 14:08 airwin * examples/c/Makefile.examples.in: rm ==> rm -f 2003-10-03 18:28 airwin * bindings/c++/plstream.cc: AWI for Andrew Ross <an...@co...>. Correct problem with too many lines commented out while removing the plinit() calls from the plstream constructor. This two-line change to the API does not affect the current examples, but according to Andrew does affect other programmes using the PLplot C++ API. 2003-10-02 08:47 airwin * Makefile.am: Bug fix for changed way we now handle libltdl. Only do libltdl directory for case when dyndrivers are enabled. 2003-10-01 23:05 airwin * bindings/java/README.javaAPI: Update documentation to reflect building of installed java examples that now occurs automatically and the new installed location for the module (DLL) for the java PLplot interface. 2003-10-01 22:52 airwin * bindings/java/Makefile.am: Complete reorganization following what is done for ../../bindings/python/Makefile.am. Note that install-exec-hook: is now used to compile all the installed java files rather than compiling them in a local directory underneath bindings/java before installation, and this reduces a lot of clutter that was occurring before. Another notable change is the java module that interfaces to PLplot is no longer built like a full-blown library with a version number, precision tag, etc. with installation into $prefix/lib with appropriate version number symlinks. Instead, it is built similarly to the python module and installed in the location where the core java and compiled class files are installed. 2003-10-01 22:41 airwin * bindings/java/: PLStreamc.java, config.java.in: For PLStreamc.java, change from System.loadLibrary( plplot.core.config.libname ); to System.load( plplot.core.config.libname ); The former requires setting LD_LIBRARY_PATH on Linux/Unix systems (ugh, that is old-fashioned!). The latter requires an absolute path name + exact name of dynamically loaded module which is setup in configure.ac and configured using config.java.in. Yipee! No more setting of LD_LIBRARY_PATH is required for PLplot java use! 2003-10-01 22:29 airwin * configure.ac: * Only do libltdl related actions if dyndrivers is enabled. * Define AC_SUBSTituted variables JAVA_INSTDIR and PLPLOTJAVAC_WRAP_DLL for the absolute path of the Java install location, and the name of the module for interfacing java to PLplot that is (now) installed in that location. 2003-10-01 22:22 airwin * acinclude.m4: Add another macro, GET_DLLNAME, for getting the name for dynamically loaded libraries (modules). This macro has largely been copied from GET_DLNAME. On many systems the name for modules is just simply namestem.so, but we cannot assume that for all Unix platforms. 2003-10-01 22:12 airwin * bindings/python/README.pythonbuild: Tweak wording to reflect Mac OS X success. 2003-10-01 22:10 airwin * bindings/python/Makefile.am: Drop -no-undefined from LDFLAGS for the creation of the module that will be dynamically loaded by python. It makes no sense to resolve every reference at link time since python will be supplying the references to the python library names at dynamic load time. (Thanks to Rob Managan for his Mac OS X error report on this issue.) 2003-10-01 22:03 airwin * examples/java/README.javademos: Update documentation reflecting the automatic build of the examples by make install. 2003-10-01 21:59 airwin * test/test_java.sh: Update commentary. 2003-10-01 21:54 airwin * examples/java/Makefile.am: Compile java examples after installation. This is contrary to what we do for our other compiled language examples, but seems consistent with what is normally done for distribution of java software. 2003-10-01 21:50 airwin * examples/c++/Makefile.am: $(LN_S) must be preceded by rm -f. (Thanks to Rob Managan for his error report concerning this issue.) 2003-10-01 21:38 airwin * doc/docbook/: docbook.m4, src/Makefile.am: As discussed on the list deal with SourceForge username consistently both for configure time using the --with-www-user=NAME option and at make time overriding the WWW_USER variable using make WWW_USER=NAME Previously, overriding the make variable required a trailing @ in the NAME, but now NAME is treated identically in both cases with no trailing @ required. 2003-10-01 12:58 rlaboiss * configure.ac, include/plConfig.h.in: Better wording in comment for PL_DOUBLE The comment preceeding #define PL_DOUBLE is now clearer. Thanks to Arjen Markus <arj...@wl...> for the suggestion. |
From: Rafael L. <lab...@ps...> - 2003-10-02 20:45:15
|
----- Forwarded message from "Alan W. Irwin" <ir...@be...> ----- From: "Alan W. Irwin" <ir...@be...> Subject: Announcing today's experimental test PLplot tarball Date: Thu, 2 Oct 2003 11:37:15 -0700 (PDT) To: Rafael Laboissiere <lab...@ps...> Here is a new version of the experimental PLplot tarball for testing purposes on Mac OS X and Cygwin (or any other platform where you want to be on the PLplot cutting edge). See the Debian stable, Mac OS X and Cygwin status reports below. All are looking pretty good! Use at your own risk! There are still some security concerns with the Debian unstable libtool-1.5 application we used to build this tarball, but James Remnant is adamant (see his public remarks in response to my concerns at http://www.mail-archive.com/deb...@li.../msg10149.html) that he has tracked every change in cvs for a long time since well before the cracker rooted the GNU ftp server, and therefore no malicious code can possibly be in the Debian unstable libtool-1.5 package. So please review his remarks, and make your own judgement call on this issue. what: plplot-5.2.1.cvs.20031002.tar.gz and plplot-5.2.1.cvs.20031002.tar.gz.asc (detached PGP signature. Use gpg --verify to verify that there are no transmission errors and that Rafael is the source of these files). where: the usual test tarball site; http://people.debian.org/~rafael/plplot.html. Thanks, Rafael, for producing this. I have tested this tarball on my Debian stable system both for ./configure defaults (which implies enabling of shared libraries and dynamic drivers) and for the combination of --disable-shared and --disable-dyndrivers. There were no obvious build problems and all test examples built and gave good results. I have just incorporated a series of improvements in PLplot which got into this new experimental tarball. This effort incorporated much appreciated feedback from Rob Managan with results on his Mac OS X system and Ullal Devappa Kini with results on his Cygwin system. _______________________________________________ Here is a summary of the current PLplot status on Mac OS X. (For Cygwin results see below.) * Rob must always use --disable-dyndrivers because get-drv-info does not work on his system. Rafael now has some diagnostic output to play with. This is the only PLplot Mac OS X issue left where we feel there is something we might be able to do about the situation. * Rob must use -dev xwin -drvopt defvis to work around X server problems on Mac OS X. * For the default shared libraries, C, C++, and python worked without problems. Rob did not try java, tcl/tk, or octave. * Rob had to --disable-f77 for the default shared libraries because of a limitation of the Mac OS X loader; apparently it cannot handle fortran common blocks (which our fortran interface code uses) for shared libraries. The combination of --enable-f77 --disable-shared does work for Rob. However, disable-shared does have the side effect of large executables, and it also disallows use of our python, java, and octave interfaces (all of which depend on shared libraries). _______________________________________________ Here is a summary of the current PLplot status on Cygwin. (For Mac OS X results see above.) * When Ullal ran ./configure with lots of options from inside a script there appeared to be some problems with the Cygwin shell (whether ash or bash). He is still investigating this problem, but for now using ./configure from the command line seems to work. * Ullah so far has investigated only the case of --disable-shared --disable-dyndrivers. This necessarily eliminates the python, java, and octave interfaces to PLplot which depend on shared libraries. Thus, if you are interested in any of these languages on Cygwin it would be well worthwhile to at least attempt the default --enable-shared. (Probably in such an attempt you should continue with --disable-dyndrivers.) * It appears that Cygwin Tcl has been limited to the cross-platform subset Tcl code with the Unix Tcl extensions not available for this Unix platform. (!) Since PLplot requires the Tcl Unix extensions, you must --disable-tcl on Cygwin. * Ullal finds the c, c++, and fortran interfaces to PLplot (for the static libraries no dynamic drivers case) all work fine. He has interactively generated pbm, png, jpeg, xfig, plmeta, ps, and psc files and displayed them with the appropriate applications (including plrender to display the metafile format of the plmeta result). The xterm device apparently does not work for Ullal, although he hasn't clarified whether he actually ran that from an xterm GUI (which is, of course, a requirement). _______________________________________________ In sum, Debian stable, Mac OS X and Cygwin are all looking pretty good for the current, experimental PLplot tarball, and my thanks to Rob and Ullah for all the hard, repetitive testing work they put in to help achieve this good result. I encourage you to try out the current experimental PLplot tarball on other platforms as well (or on Mac OS X or Cygwin platforms for even more extensive testing or just plain use) _if_ you are willing to make your own judgement on the security risk mentioned above. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ----- End forwarded message ----- -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-09-22 01:49:23
|
OK, here is the long awaited _experimental_ PLplot test tarball for cygwin and macosx systems. what: plplot-5.2.1.cvs.20030921.tar.gz and plplot.md5sum (a gpg-signed file containing the md5sum for the tarball). where: the usual test tarball site; http://people.debian.org/~rafael/plplot.html. Thanks, Rafael, for producing this. This tarball is based on today's PLplot snapshot which contains some changes (in particular a C++ API change and also a large extension of that API plus a whole set of the standard examples written in C++ that use all the updates to that API) since the 5.2.1 release. The tarball has been built with the latest autotools available on Debian unstable. These include a libtool cvs snapshot taken slightly after the release of libtool-1.5. Our previous release 5.2.1 tarball, plplot-5.2.1.tar.gz, was built with libtool-1.4.3 which had well-known problems for macosx and cygwin platforms. PLplot users on those platforms confirm there are many problems with PLplot-5.2.1, but we are hoping that a PLplot tarball generated with libtool-1.5 will fix those problems. Thus, we suggest it might be worthwhile (but see CAVEATS below) to test out this experimental tarball on cygwin and macosx systems to see what PLplot problems (if any) there are on those systems now with a PLplot tarball built with libtool-1.5. Also, you might want to try out this experimental tarball if you would like to take advantage of the greatly improved (but changed!, see the examples in examples/c++ ) C++ API for PLplot (put together by Andrew Ross). CAVEATS: This is an _experimental_ tarball so use with some caution. I have done my usual tests on the two platforms available to me (Debian stable and RedHat 7.3), but that is just a start and we need lots more testing for a variety of configurations and platforms before we can even think of calling this version of the PLplot code non-experimental. Also, there are some security concerns because this tarball is built with libtool-1.5, and there is long-drawn out uncertainty whether malicious code has been inserted into it by the GNU cracker that owned the GNU ftp server for many months before that crack was discovered last month. Because of this problem, GNU have rightly withdrawn all their ~500 newer source tarballs and are in the process of testing each one for malignant code before re-releasing the tarball (currently at the rate of about 1 per day). So far for the many older tarballs (which were easy to test because GNU had access to untainted sources) there were absolutely no problems and they were able to restore them with confidence. However, libtool-1.5 is one of the newer tarballs which have not yet been restored. Nevertheless, the Debian libtool packager, James Remnant is adamant (see his public remarks at response to my concerns at http://www.mail-archive.com/deb...@li.../msg10149.html) that he has tracked every change in cvs for a long time since well before the cracker rooted the GNU ftp server, and therefore no malicious code can possibly be in the Debian unstable libtool-1.5 package. My own judgement call is I trust what he says because he stated it so strongly and publically on the Debian security list so that is good enough for me, and I am obviously willing to try this tarball on the machines accessible to me as a result. But you will have to make your own judgement call based on your reading of that thread (or wait many months to get access to a libtool-1.5 tarball that GNU will officially vouch for and an official release of PLplot from us based on that). I am sorry for this security cloud that continues to hang over one of the more important free software development tools, but all I can do about it is to keep you honestly informed, and agitate with the libtool developers to verify their version 1.5 tarball so that GNU will officially release it again. However, so far the libtool developers see no urgency in doing this boring task. Thus, Rafael and I decided to use the Debian unstable libtool-1.5 workaround which is vouched for by James Remnant to generate this experimental PLplot tarball, but it is definitely a "use at your own risk" situation. If you do try this experimental PLplot tarball, please send your reports both positive and negative to plplot_devel. We especially need to know the details of your platform, and if the report is negative the complete output of the ./configure; make; and make install commands. BTW, for my tests of this tarball I took defaults for the ./configure options except for --prefix. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-09-11 23:01:19
|
On Thursday 11 September 2003 17:09, Alan W. Irwin wrote: | On 2003-09-11 08:49-0500 Herng-Jeng Jou wrote: | > BTW, it is my understanding that Plplot constructs contour plot only | > from gridded data, not from ungridded data. | | That's an easy question to answer. For 5.2.1, plgriddata gives us a | powerful capability to transform from ungridded data to the gridded data | required for the PLplot routines that actually plot. | | From the 5.2.1 announcement at | http://plplot.sourceforge.net/announce-plplot-5.2.1.html: | | "plgriddata. Generate grid data for 3D plots from irregularly sampled | data." | | "3D" here should be interpreted in its broadest sense; any plot (contour, | 3D perspective, shade, 3D shade, etc.) which involves 3D data. plgriddata | is documented in | | http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.1.cv |s.20030828/plgriddata.html. One example of its use is given in example 21 | which involves 3D perspective plots and 3D shaded plots, but it should be | easy to adapt example/c/x21c.c for contoured plots as well. | | We should thank Joao Cardoso for donating the plgriddata code to the | PLplot project. Hi, plgriddata() uses several algorithms to perform its task. The simplest are nearest neighbors (KNN) based, and require no additional libraries; the more sophisticated algorithms uses the csa (cubic spline approximation) and nn (Natural Neighbours) libraries, both authored by Pavel Sakov (http://www.marine.csiro.au/~sakov/) and both included in the plplot distribution. The nn library needs in addition the qhull library, which is not included in plplot, but it's easy to build and can be obtained at http://savannah.nongnu.org/projects/qhull Good luck Joao | | 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 PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the | Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project | (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-general mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Alan W. I. <ir...@be...> - 2003-09-11 16:09:35
|
On 2003-09-11 08:49-0500 Herng-Jeng Jou wrote: > BTW, it is my understanding that Plplot constructs contour plot only from > gridded data, not from ungridded data. That's an easy question to answer. For 5.2.1, plgriddata gives us a powerful capability to transform from ungridded data to the gridded data required for the PLplot routines that actually plot. From the 5.2.1 announcement at http://plplot.sourceforge.net/announce-plplot-5.2.1.html: "plgriddata. Generate grid data for 3D plots from irregularly sampled data." "3D" here should be interpreted in its broadest sense; any plot (contour, 3D perspective, shade, 3D shade, etc.) which involves 3D data. plgriddata is documented in http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.1.cvs.20030828/plgriddata.html. One example of its use is given in example 21 which involves 3D perspective plots and 3D shaded plots, but it should be easy to adapt example/c/x21c.c for contoured plots as well. We should thank Joao Cardoso for donating the plgriddata code to the PLplot project. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Herng-Jeng J. <hj...@qu...> - 2003-09-11 13:51:48
|
Thanks a lot for your help and great work. I'll wait couple days then for the new cvs to be posted. BTW, it is my understanding that Plplot constructs contour plot only from gridded data, not from ungridded data. Am I correct? If so, what code would you recommend to generate gridded data from ungridded data? Jou At 09:09 AM 9/10/2003 -0700, you wrote: >On 2003-09-10 08:36-0600 Vince Darley wrote: > > > (The new version should appear in public cvs in 24 hours). > >24 hours is what SourceForge advertises, but my experience last week was the >public cvs was running behind the developer version by at least 4 days. A >quick way to check is to use the viewcvs browser at >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plplot/plplot/sys/win-tk/ >to see what the dates are on makePlplotStarkit.tcl and makefile.vc, the two >files Vince recently updated. > >Appropriately change the above directory to check for the availability of >any other recent cvs commit on the delayed public cvs server. > >Note also, that SourceForge are apparently installing new cvs server >hardware this month to alleviate the delay problems, but we will just have >to wait and see how effective their fix is going to be. > >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 PLplot scientific plotting software >package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the >Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project >(lbproject.sf.net). >__________________________ > >Linux-powered Science >__________________________ > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Plplot-general mailing list >Plp...@li... >https://lists.sourceforge.net/lists/listinfo/plplot-general ======================================= Herng-Jeng Jou QuesTek Innovations, LLC hj...@qu... |
From: Alan W. I. <ir...@be...> - 2003-09-10 16:11:55
|
On 2003-09-10 08:36-0600 Vince Darley wrote: > (The new version should appear in public cvs in 24 hours). 24 hours is what SourceForge advertises, but my experience last week was the public cvs was running behind the developer version by at least 4 days. A quick way to check is to use the viewcvs browser at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plplot/plplot/sys/win-tk/ to see what the dates are on makePlplotStarkit.tcl and makefile.vc, the two files Vince recently updated. Appropriately change the above directory to check for the availability of any other recent cvs commit on the delayed public cvs server. Note also, that SourceForge are apparently installing new cvs server hardware this month to alleviate the delay problems, but we will just have to wait and see how effective their fix is going to be. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Vince D. <vi...@sa...> - 2003-09-10 14:36:55
|
I've committed a couple of small fixes to the win-tk build. The problem is that plplot's build/config (and even data directories and #defines) have changed a number of times in the last few years and I haven't always kept win-tk/makefile.vc up to date. (The new version should appear in public cvs in 24 hours). Note: if you want a slightly older .dll, it is available (with demos) at the 'starkit archive'. thanks, -- Vince <http://www.santafe.edu/~vince> On Tue, 9 Sep 2003, Herng-Jeng Jou wrote: > Hi, > I downloaded plplot 5.2.1, compiled win32 with no problem with VC++ 6.0. > Then I was trying to compiled the win-tk dll. Following the instruction of > Readme.txt, the first error I found was not finding "ltdl.h" file when > compiling > plcore.c. After adding -I..\..\libltdl into compile flag, it was found. > Then following errors > occur when compiling plcore.c: > > ..\..\src/../include\plConfig.h(48) : warning C4005: 'DATA_DIR' : macro > redefinition > unknown(0) : see previous definition of 'DATA_DIR' > ..\..\libltdl\ltdl.h(332) : error C2061: syntax error : identifier 'UNKNOWN' > : > : > : many warning messages > : > ..\..\src\plcore.c(1630) : error C2065: 'DIR' : undeclared identifier > ..\..\src\plcore.c(1630) : error C2065: 'dp_drvdir' : undeclared identifier > ..\..\src\plcore.c(1630) : warning C4047: '=' : 'int ' differs in levels of > indirection from 'void *' > ..\..\src\plcore.c(1630) : error C2106: '=' : left operand must be l-value > ..\..\src\plcore.c(1631) : error C2143: syntax error : missing ';' before > 'type' > ..\..\src\plcore.c(1632) : error C2275: 'lt_dlhandle' : illegal use of this > type as an expression > ..\..\libltdl\ltdl.h(148) : see declaration of 'lt_dlhandle' > ..\..\src\plcore.c(1632) : error C2146: syntax error : missing ';' before > identifier 'dlhand' > ..\..\src\plcore.c(1632) : error C2065: 'dlhand' : undeclared identifier > ..\..\src\plcore.c(1640) : warning C4013: 'opendir' undefined; assuming > extern returning int > ..\..\src\plcore.c(1641) : warning C4047: '==' : 'int ' differs in levels > of indirection from 'void *' > ..\..\src\plcore.c(1647) : error C2065: 'entry' : undeclared identifier > ..\..\src\plcore.c(1647) : warning C4013: 'readdir' undefined; assuming > extern returning int > ..\..\src\plcore.c(1647) : warning C4047: '!=' : 'int ' differs in levels > of indirection from 'void *' > ..\..\src\plcore.c(1649) : error C2223: left of '->d_name' must point to > struct/union > > Could anybody help me resolve these problem? > Or can somebody can share the built dll with me? > > Thanks a lot. > > Jou > > > ======================================= > Herng-Jeng Jou > QuesTek Innovations, LLC > 1820 Ridge Avenue > Evanston, IL 60201 > (Tel) 847.425.8221 > (Fax) 847.328.5855 > hj...@qu... > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > |
From: Herng-Jeng J. <hj...@qu...> - 2003-09-09 19:02:28
|
Hi, I downloaded plplot 5.2.1, compiled win32 with no problem with VC++ 6.0. Then I was trying to compiled the win-tk dll. Following the instruction of Readme.txt, the first error I found was not finding "ltdl.h" file when compiling plcore.c. After adding -I..\..\libltdl into compile flag, it was found. Then following errors occur when compiling plcore.c: ..\..\src/../include\plConfig.h(48) : warning C4005: 'DATA_DIR' : macro redefinition unknown(0) : see previous definition of 'DATA_DIR' ..\..\libltdl\ltdl.h(332) : error C2061: syntax error : identifier 'UNKNOWN' : : : many warning messages : ..\..\src\plcore.c(1630) : error C2065: 'DIR' : undeclared identifier ..\..\src\plcore.c(1630) : error C2065: 'dp_drvdir' : undeclared identifier ..\..\src\plcore.c(1630) : warning C4047: '=' : 'int ' differs in levels of indirection from 'void *' ..\..\src\plcore.c(1630) : error C2106: '=' : left operand must be l-value ..\..\src\plcore.c(1631) : error C2143: syntax error : missing ';' before 'type' ..\..\src\plcore.c(1632) : error C2275: 'lt_dlhandle' : illegal use of this type as an expression ..\..\libltdl\ltdl.h(148) : see declaration of 'lt_dlhandle' ..\..\src\plcore.c(1632) : error C2146: syntax error : missing ';' before identifier 'dlhand' ..\..\src\plcore.c(1632) : error C2065: 'dlhand' : undeclared identifier ..\..\src\plcore.c(1640) : warning C4013: 'opendir' undefined; assuming extern returning int ..\..\src\plcore.c(1641) : warning C4047: '==' : 'int ' differs in levels of indirection from 'void *' ..\..\src\plcore.c(1647) : error C2065: 'entry' : undeclared identifier ..\..\src\plcore.c(1647) : warning C4013: 'readdir' undefined; assuming extern returning int ..\..\src\plcore.c(1647) : warning C4047: '!=' : 'int ' differs in levels of indirection from 'void *' ..\..\src\plcore.c(1649) : error C2223: left of '->d_name' must point to struct/union Could anybody help me resolve these problem? Or can somebody can share the built dll with me? Thanks a lot. Jou ======================================= Herng-Jeng Jou QuesTek Innovations, LLC 1820 Ridge Avenue Evanston, IL 60201 (Tel) 847.425.8221 (Fax) 847.328.5855 hj...@qu... |