From: Alan W. I. <ai...@us...> - 2003-12-28 21:11:20
|
On 2003-12-28 15:32-0500 Koen van der Drift wrote: > > On Dec 26, 2003, at 1:12 PM, Alan W. Irwin wrote: > > > Then in that same directory to execute the built example: > > > > ./x01c -dev psc -o temp.ps > > > > which creates the result file temp.ps containing the coloured > > postscript > > plot of our example 1. > > > > Yes, that works (tested with latest cvs release)! Excellent. > But it only works if > plplot gets installed into /usr/local/. My goal is to create a plplot > package for the fink project, which is a debian-type package manager > for Mac OS X. Fink installs everything into a special dedicated > directory /sw. If I run the examples from /sw/share/plplot/examples, I > get an error about fonts: > > *** PLPLOT ERROR *** > Unable to open or allocate memory for font file > Program aborted. > > > Does plplot install its own fonts (and where)? Yes, fonts (and needed geographical map information for one of the examples) is installed automatically in $prefix/lib/plplot$version/data That translates to /usr/local/plplot_at/lib/plplot5.2.1/data in my case because I am using --prefix=/usr/local/plplot_at, and the fonts (and maps) are found without difficulty for this unique prefix (and should be for any other configuration prefix). I suspect what is going on is your fink install is using a staging area (similar to what goes on with both rpm and deb builds before the binary package is formed). In the rpm case, we use a ./configure prefix corresponding to the final install area (./configure --prefix=/usr in that case, and ./configure --prefix=/sw in the fink case), and we install in the staging area using the following command: make DESTDIR=/staging_area install where /staging_area is the absolute path of the staging area where fink temporarily installs before putting its final binary package together. BTW, this new topic seems more suitable for plplot-devel rather than plplot-general so I have switched it to that list with a new subject line. 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: Koen v. d. D. <kvd...@ea...> - 2004-01-04 09:59:58
|
On Jan 4, 2004, at 4:49 AM, Michel Peyrard wrote: > > I am not sure I undersood all the exchanges concerning the pthreads > problem on Mac OS X. > > I made the following trial: > > ---- modification of xwin.c --- > #ifdef HAVE_PTHREAD > #include <pthread.h> > #include <signal.h> > int pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int > kind); > static void events_thread(void *pls); > static pthread_mutex_t events_mutex; > static int already = 0; > #endif > > #define __APPLE__ > #ifdef __APPLE__ > #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE > #define pthread_mutexattr_setkind_np pthread_mutexattr_setkind > #endif > Michel, Try putting the #define __APPLE__ section above the #ifdef HAVE_PTHREAD section. And change #define pthread_mutexattr_setkind_np pthread_mutexattr_setkind to #define pthread_mutexattr_setkind_np pthread_mutexattr_settype Also, the line #define __APPLE__ is not really necessary, I think. - Koen. |
From: Michel P. <Mic...@en...> - 2004-01-04 10:47:47
|
Using the modified xwin.c below, and make F77="g77 -lcc_dynamic" to take care of the fortran problem, I can compile the tarball 20031231 with pthreads and shared-libs, including fortran, on Mac OSX. (I am not sure that the exit from the program works normally, however. The xwindow seems to persist and I have to close it by hand; but, as I am doing X through a modem, it is very slow and this could be at the origin of the problem) It seems that the only problem that persits on Mac OSX is the need to disable dyndrivers. Michel ---- modified xwin.c ----- PLplot X-windows device driver. */ #include "plDevs.h" #define DEBUG #ifdef PLD_xwin #define NEED_PLDEBUG #include "plplotP.h" #include "plxwd.h" #include "drivers.h" #include "plevent.h" #ifdef __APPLE__ #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE #define pthread_mutexattr_setkind_np pthread_mutexattr_settype #endif #ifdef HAVE_PTHREAD #include <pthread.h> #include <signal.h> |
From: Koen v. d. D. <kvd...@ea...> - 2003-12-29 14:20:44
|
On Dec 28, 2003, at 4:11 PM, Alan W. Irwin wrote: >> Yes, that works (tested with latest cvs release)! > > Excellent. The python examples also work. > Yes, fonts (and needed geographical map information for one of the > examples) > is installed automatically in $prefix/lib/plplot$version/data > > That translates to /usr/local/plplot_at/lib/plplot5.2.1/data in my case > because I am using --prefix=/usr/local/plplot_at, and the fonts (and > maps) > are found without difficulty for this unique prefix (and should be for > any > other configuration prefix). > > I suspect what is going on is your fink install is using a staging area > (similar to what goes on with both rpm and deb builds before the binary > package is formed). In the rpm case, we use a ./configure prefix > corresponding to the final install area (./configure --prefix=/usr in > that > case, and ./configure --prefix=/sw in the fink case), and we install > in the > staging area using the following command: > > make DESTDIR=/staging_area install > > where /staging_area is the absolute path of the staging area > where fink temporarily installs before putting its final binary package > together. I think I figured out what is going on. For the fink package I moved all the data and examples from /sw/lib/plplot/ to /sw/share/plplot, which is where the fink docs recommend to put architecture independent stuff. Apparently the examples expect the fonts to be in /sw/lib/plplot which is why I get the error. If I leave everything in /sw/lib/plplot, the examples work fine. So I will leave the examples, etc in /sw/lib, unless there is a way I can fix the font path rather easily, maybe by applying a patch? - Koen. |
From: Rafael L. <rla...@us...> - 2003-12-29 16:44:58
|
* Koen van der Drift <kvd...@ea...> [2003-12-29 09:04]: > I think I figured out what is going on. For the fink package I moved > all the data and examples from /sw/lib/plplot/ to /sw/share/plplot, > which is where the fink docs recommend to put architecture independent > stuff. Apparently the examples expect the fonts to be in /sw/lib/plplot > which is why I get the error. If I leave everything in /sw/lib/plplot, > the examples work fine. So I will leave the examples, etc in /sw/lib, > unless there is a way I can fix the font path rather easily, maybe by > applying a patch? You can override the path for the data files with the DATA_DIR environment variable. Using bash, you can do this, for instance: DATA_DIR=share/plplot/data ./configure and the data files will land on $prefix/share/plplot/data. The problem with this approach is that the driver modules (which *_are_* architecture-dependent) will be installed in $prefix/share/plplot/driversd. One way to overcome this is by doing (okay, that's tricky, but you asked for it; and, hey, no patches needed!): DATA_DIR=share/plplot/data DRV_DIR=../../../lib/plplot/drivers ./configure Notice the "../../.." needed in the definition of the environment variable DRV_DIR. This is because the core code of the PLplot library composes the drivers directory like this (in src/plcore.c): drvdir = DATA_DIR "/" DRV_DIR; However, this may be a non-issue for Fink right now, because dynamical loading of driver modules does not work on Mac OS X (yet). An unrelated question, just out of curiosity: my knowledge of Fink is almost zero, but I know it is dpkg-based. How much from my Debian packaging work are you using in order to build the Fink PLplot package? -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2003-12-29 20:54:03
|
Hi all, I have been able to do some more testing, and I now also have the tcl/tk scripting and examples working, although I get the following warning when making the examples: [ModusOperandi:plplot5.2.1.cvs.20031228/examples/c] koen% sudo make plplot_libtool --mode=link gcc -g -O2 x01c.c -I/sw/include/plplot -L/sw/lib -lplplotd -o x01c mkdir .libs gcc -g -O2 x01c.c -I/sw/include/plplot -o x01c -L/sw/lib /sw/lib/libplplotd.dylib /sw/lib/libcsirocsa.dylib -ltk -ltcl -L/usr/X11R6/lib -lX11 -lm ld: warning multiple definitions of symbol _tclPlatStubsPtr /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclPlatStubsPtr /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclPlatStubsPtr ld: warning multiple definitions of symbol _tclIntStubsPtr /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntStubsPtr /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntStubsPtr ld: warning multiple definitions of symbol _Tcl_InitStubs /sw/lib/libtcl.dylib(tclStubLib.o) definition of _Tcl_InitStubs /sw/lib/libtk.dylib(tclStubLib.o) definition of _Tcl_InitStubs ld: warning multiple definitions of symbol _tclIntPlatStubsPtr /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr ld: warning multiple definitions of symbol _tclStubsPtr /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclStubsPtr /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclStubsPtr ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _Tcl_InitStubs used from dynamic library /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /sw/lib/libtk8.4.dylib(tclStubLib.o) symbol _tclIntPlatStubsPtr used from dynamic library /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /sw/lib/libtk8.4.dylib(tclStubLib.o) symbol _tclIntStubsPtr used from dynamic library /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /sw/lib/libtk8.4.dylib(tclStubLib.o) symbol _tclPlatStubsPtr used from dynamic library /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /sw/lib/libtk8.4.dylib(tclStubLib.o) symbol _tclStubsPtr used from dynamic library /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /sw/lib/libtk8.4.dylib(tclStubLib.o) symbol _TclSetStartupScriptFileName used from dynamic library /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library /sw/lib/libplplotd.9.dylib(tclMain.o) symbol _TclGetStartupScriptFileName used from dynamic library /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library /sw/lib/libplplotd.9.dylib(tclMain.o) Are these harmless? Also, to enable output in png and jpeg, I installed the necessary packahes from fink, and as seen below, lgd, lpng, ljpeg and lz are all found: ... configure: WARNING: Java Native Interface include file not found, configure: WARNING: setting enable_java=no checking for GD header files... found in default checking for main in -lgd... yes checking for main in -lpng... yes checking for main in -ljpeg... yes checking for main in -lz... yes checking for png support in libgd... no configure: WARNING: png driver disabled checking for jpeg support in libgd... no configure: WARNING: jpeg driver disabled checking for libcd header files... not found configure: WARNING: libcd header files not found, setting enable_cgm=no checking for main in -lcd... no configure: WARNING: cd library not found, setting enable_cgm=no checking for freetype library header files... not found configure: WARNING: freetype header files not found, configure: WARNING: setting with_freetype=no checking for main in -lfreetype... no configure: WARNING: freetype library not found, setting with_freetype=no ... As you can see there is a problem with libgd, so enable_png and enable_jpeg are set to no. What version of the gd package are you using, maybe fink has a wrong version? The other error is about the freetype files, which cannot be found. I have XWindows installed, and know that other packages are able to use the freetype files. If freetype support is important to plplot, is there a way I can fix this? thanks, - Koen. |
From: Alan W. I. <ai...@us...> - 2003-12-29 22:59:20
|
On 2003-12-29 15:52-0500 Koen van der Drift wrote: > Hi all, > > I have been able to do some more testing, and I now also have the > tcl/tk scripting and examples working, although I get the following > warning when making the examples: > > > [ModusOperandi:plplot5.2.1.cvs.20031228/examples/c] koen% sudo make > plplot_libtool --mode=link gcc -g -O2 x01c.c -I/sw/include/plplot > -L/sw/lib -lplplotd -o x01c > mkdir .libs > gcc -g -O2 x01c.c -I/sw/include/plplot -o x01c -L/sw/lib > /sw/lib/libplplotd.dylib /sw/lib/libcsirocsa.dylib -ltk -ltcl > -L/usr/X11R6/lib -lX11 -lm > ld: warning multiple definitions of symbol _tclPlatStubsPtr > /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclPlatStubsPtr > /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclPlatStubsPtr > ld: warning multiple definitions of symbol _tclIntStubsPtr > /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntStubsPtr > /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntStubsPtr > ld: warning multiple definitions of symbol _Tcl_InitStubs > /sw/lib/libtcl.dylib(tclStubLib.o) definition of _Tcl_InitStubs > /sw/lib/libtk.dylib(tclStubLib.o) definition of _Tcl_InitStubs > ld: warning multiple definitions of symbol _tclIntPlatStubsPtr > /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr > /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr > ld: warning multiple definitions of symbol _tclStubsPtr > /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclStubsPtr > /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclStubsPtr > ld: warning suggest use of -bind_at_load, as lazy binding may result in > errors or different symbols being used > symbol _Tcl_InitStubs used from dynamic library > /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library > /sw/lib/libtk8.4.dylib(tclStubLib.o) > symbol _tclIntPlatStubsPtr used from dynamic library > /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library > /sw/lib/libtk8.4.dylib(tclStubLib.o) > symbol _tclIntStubsPtr used from dynamic library > /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library > /sw/lib/libtk8.4.dylib(tclStubLib.o) > symbol _tclPlatStubsPtr used from dynamic library > /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library > /sw/lib/libtk8.4.dylib(tclStubLib.o) > symbol _tclStubsPtr used from dynamic library > /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library > /sw/lib/libtk8.4.dylib(tclStubLib.o) > symbol _TclSetStartupScriptFileName used from dynamic library > /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library > /sw/lib/libplplotd.9.dylib(tclMain.o) > symbol _TclGetStartupScriptFileName used from dynamic library > /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library > /sw/lib/libplplotd.9.dylib(tclMain.o) > > Are these harmless? Possibly, although it looks like there are some general nameclash issues (same symbols defined in both libraries) that need to be sorted out for the tcl and tk libraries in Mac OS X. To make sure these issues are harmless, I suggest doing the following tcl/tk tests for PLplot: Try ./x01c -dev tk Does that interactive device (that depends on tcl/tk) work? Also in the _installed_ examples directory (or copy of it) try the ./plplot-test.sh script. That is a comprehensive check that all the language interfaces (including tcl) are working properly for file devices. Lots of different plots (postscript by default, but try ./plplot-test.sh --help to see about other file device alternatives) are produced so don't give up on this command if not many messages are being printed as it executes. Also try some of the interactive checks of tcl/tk mentioned in examples/tcl/README.tcldemos and examples/tk/README.tkdemos. > > > Also, to enable output in png and jpeg, I installed the necessary > packahes from fink, and as > seen below, lgd, lpng, ljpeg and lz are all found: > > ... > configure: WARNING: Java Native Interface include file not found, > configure: WARNING: setting enable_java=no > checking for GD header files... found in default > checking for main in -lgd... yes > checking for main in -lpng... yes > checking for main in -ljpeg... yes > checking for main in -lz... yes > checking for png support in libgd... no > configure: WARNING: png driver disabled > checking for jpeg support in libgd... no > configure: WARNING: jpeg driver disabled > checking for libcd header files... not found > configure: WARNING: libcd header files not found, setting enable_cgm=no > checking for main in -lcd... no > configure: WARNING: cd library not found, setting enable_cgm=no > checking for freetype library header files... not found > configure: WARNING: freetype header files not found, > configure: WARNING: setting with_freetype=no > checking for main in -lfreetype... no > configure: WARNING: freetype library not found, setting with_freetype=no > ... > > As you can see there is a problem with libgd, so enable_png and > enable_jpeg are set to no. What version of the gd package are you > using, maybe fink has a wrong version? The above message means every required gd header, and png, jpeg, and zlib library was found, but this section of sysloc.in did not work correctly: AC_MSG_CHECKING(for png support in libgd) AC_TRY_LINK_FUNC([ gdImagePng ], [AC_MSG_RESULT(yes)], [ AC_MSG_RESULT(no) AC_MSG_WARN(png driver disabled) enable_png=no ]) This fails if you have a really old version of libgd (like for RH 6.2), but I doubt that is the source of the problem. For example, version 2.0.1 of libgd works fine on Debian stable, and IIRC even libgd 1.8.x worked well. What does the relevant part of your config.log say about this test? Mine reads: configure:22002: checking for png support in libgd configure:22031: gcc -o conftest -Idefault conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5 configure:22037: $? = 0 configure:22041: test -z || test ! -s conftest.err configure:22044: $? = 0 configure:22047: test -s conftest configure:22050: $? = 0 configure:22052: result: yes > > The other error is about the freetype files, which cannot be found. I > have XWindows installed, and know that other packages are able to use > the freetype files. > > If freetype support is important to plplot, is there a way I can fix > this? freetype is a way to use system fonts in PLplot rather than the default built-in (Hershey) fonts. It's a fairly new feature that currently is only implemented for the gd-associated devices (png, jpeg). See http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.1.cvs.20030929/freetype-notes.html for more discussion. Although our current support for feature is limited to these two devices, nevertheless it is a fairly interesting feature that is well worth including. From sysloc.in, currently the freetype headers are only looked for in /usr/include/freetype2 and /usr/local/include/freetype2, and similarly the freetype library is only looked for in /usr/lib and /usr/local/lib. To specify other locations set the FREETYPEINCDIR and/or FREETYPELIBDIR environment variables before running the ./configure command. 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: Koen v. d. D. <kvd...@ea...> - 2003-12-31 00:23:49
|
On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote: > To make sure these issues are harmless, I suggest doing the following > tcl/tk tests for PLplot: > > Try > > ./x01c -dev tk > > Does that interactive device (that depends on tcl/tk) work? No, I get this error: plFindCommand: cannot locate command: plserver bin dir="/sw/bin" *** PLPLOT ERROR *** Unable to fork server process Program aborted /sw/bin/plserver does exist, though. I get this error from the Mac OS X terminal's command line or from within an X window. > Also in the _installed_ examples directory (or copy of it) try the > ./plplot-test.sh script. That works, and results in plgrid.ps, plot.ps, pythondemos.ps, tcldemos.ps, and the files for c and cc and cxx. I haven't had time to look at the other tests you suggested. > This fails if you have a really old version of libgd (like for RH > 6.2), but > I doubt that is the source of the problem. For example, version 2.0.1 > of > libgd works fine on Debian stable, and IIRC even libgd 1.8.x worked > well. I have gd 2.0.12 through fink. > What does the relevant part of your config.log say about this test? > Mine > reads: > > configure:22002: checking for png support in libgd > configure:22031: gcc -o conftest -Idefault conftest.c -Ldefault > -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5 > configure:22037: $? = 0 > configure:22041: test -z > || test ! -s conftest.err > configure:22044: $? = 0 > configure:22047: test -s conftest > configure:22050: $? = 0 > configure:22052: result: yes > This is in config.log: configure:22267: checking for png support in libgd configure:22296: gcc -o conftest -Idefault conftest.c -./sw/include conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5 ld: warning -L: directory name (default) does not exist ld: warning -L: directory name (default) does not exist ld: warning -L: directory name (default) does not exist ld: warning -L: directory name (default) does not exist ld: can't locate file for: -lgd - Koen. |
From: Rafael L. <rla...@us...> - 2003-12-31 00:50:39
|
* Koen van der Drift <kvd...@ea...> [2003-12-30 19:22]: > On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote: > > >What does the relevant part of your config.log say about this test? > >Mine > >reads: > > > >configure:22002: checking for png support in libgd > >configure:22031: gcc -o conftest -Idefault conftest.c -Ldefault > >-Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5 > >configure:22037: $? = 0 > >configure:22041: test -z > > || test ! -s conftest.err > >configure:22044: $? = 0 > >configure:22047: test -s conftest > >configure:22050: $? = 0 > >configure:22052: result: yes > > > > > This is in config.log: > > configure:22267: checking for png support in libgd > configure:22296: gcc -o conftest -Idefault conftest.c -./sw/include > conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg > -lz >&5 > ld: warning -L: directory name (default) does not exist > ld: warning -L: directory name (default) does not exist > ld: warning -L: directory name (default) does not exist > ld: warning -L: directory name (default) does not exist > ld: can't locate file for: -lgd I see something really weird in both Alan's and Koen's config.log. Those "-Idefault" and "-Ldefault" should *_never_* appear there. Alan, I think that you wrote that section of GD library checks in configure.ac. Haven't you forgot a call to ADD_TO_LIBS there? -- Rafael |
From: Rafael L. <rla...@us...> - 2003-12-31 00:54:18
|
* Rafael Laboissiere <rla...@us...> [2003-12-31 01:46]: > I see something really weird in both Alan's and Koen's config.log. Those > "-Idefault" and "-Ldefault" should *_never_* appear there. Alan, I think > that you wrote that section of GD library checks in configure.ac. I meant sysloc.in, sorry. -- Rafael |
From: Alan W. I. <ai...@us...> - 2003-12-31 02:07:06
|
On 2003-12-31 01:46+0100 Rafael Laboissiere wrote: > I see something really weird in both Alan's and Koen's config.log. Those > "-Idefault" and "-Ldefault" should *_never_* appear there. Alan, I think > that you wrote that section of GD library checks in configure.ac. Haven't > you forgot a call to ADD_TO_LIBS there? Thanks for spotting that. I agree that is weird and should not happen. However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because of the "default" logic that occurs in configure.ac. But somehow that logic, e.g., GDLIBCMD= if test "$GDLIBDIR" != default; then GDLIBCMD="$GDLIBCMD -L$GDLIBDIR" fi is failing. Should default be quoted? It appears elsewhere in configure.ac that tests are sometimes done with the quotes on the second argument and sometimes not. (I hate these m4 parsing issues). 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: Rafael L. <rla...@us...> - 2003-12-31 10:04:47
|
* Alan W. Irwin <ai...@us...> [2003-12-30 18:06]: > On 2003-12-31 01:46+0100 Rafael Laboissiere wrote: > > > I see something really weird in both Alan's and Koen's config.log. Those > > "-Idefault" and "-Ldefault" should *_never_* appear there. Alan, I think > > that you wrote that section of GD library checks in configure.ac. Haven't > > you forgot a call to ADD_TO_LIBS there? > > Thanks for spotting that. I agree that is weird and should not happen. > However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because > of the "default" logic that occurs in configure.ac. But somehow that > logic, e.g., > > GDLIBCMD= > if test "$GDLIBDIR" != default; then > GDLIBCMD="$GDLIBCMD -L$GDLIBDIR" > fi > > is failing. Should default be quoted? It appears elsewhere in configure.ac > that tests are sometimes done with the quotes on the second argument and > sometimes not. (I hate these m4 parsing issues). Strictly speaking, quotes are only really necessary when we have a variables on one of the sides of the comparison (like the "$GDLIBDIR" above). This prevents from the case where the variable is above or the variable contain special shell character (like spaces and the like). This has nothing to do with m4 parsing. To answer your question, both `default' and `"default"' should give *_exactly_* the same result under Bourne shell. I still think that ADD_TO_LIBS should be called after the GD, PNG, and JPEG checks, in the same way it is done for libcd, FreeType, and Gnome. Indeed, it is in this macro that the string "default" is coped with. -- Rafael |
From: Alan W. I. <ai...@us...> - 2003-12-31 20:59:44
|
On 2003-12-31 11:00+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ai...@us...> [2003-12-30 18:06]: > > > On 2003-12-31 01:46+0100 Rafael Laboissiere wrote: > > > > > I see something really weird in both Alan's and Koen's config.log. Those > > > "-Idefault" and "-Ldefault" should *_never_* appear there. Alan, I think > > > that you wrote that section of GD library checks in configure.ac. Haven't > > > you forgot a call to ADD_TO_LIBS there? > > > > Thanks for spotting that. I agree that is weird and should not happen. > > However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because > > of the "default" logic that occurs in configure.ac. But somehow that > > logic, e.g., > > > > GDLIBCMD= > > if test "$GDLIBDIR" != default; then > > GDLIBCMD="$GDLIBCMD -L$GDLIBDIR" > > fi > > > > is failing. Should default be quoted? It appears elsewhere in configure.ac > > that tests are sometimes done with the quotes on the second argument and > > sometimes not. (I hate these m4 parsing issues). > > Strictly speaking, quotes are only really necessary when we have a > variables on one of the sides of the comparison (like the "$GDLIBDIR" > above). This prevents from the case where the variable is above or the > variable contain special shell character (like spaces and the like). > This has nothing to do with m4 parsing. > > To answer your question, both `default' and `"default"' should give > *_exactly_* the same result under Bourne shell. Thanks for that clarification. > > I still think that ADD_TO_LIBS should be called after the GD, PNG, and JPEG > checks, in the same way it is done for libcd, FreeType, and Gnome. Indeed, > it is in this macro that the string "default" is coped with. I just realized the above logic actually works fine. grep CMD Makefile CDINCCMD = CDLIBCMD = -lcd FREETYPEINCCMD = -I/usr/include/freetype2 FREETYPELIBCMD = -lfreetype GDINCCMD = GDLIBCMD = -lgd -lpng -ljpeg -lz ITCLINCCMD = -I/usr/include/tcl8.3/itcl-private/generic ITCLLIBCMD = -litcl3.1 ITKLIBCMD = -litk3.1 JAVAINCCMD = -I/home/software/java/IBMJava2-14//include -I/home/software/java/IBMJava2-14//include TCLINCCMD = -I/usr/include/tcl8.3/tcl-private/generic TCLLIBCMD = -ltcl8.3 TKINCCMD = -I/usr/include/tcl8.3/tk-private/generic -I/usr/X11R6/include TKLIBCMD = -ltk8.3 but the above logic occurs after sysloc.in so does not affect the sysloc.in test that was producing the -Ldefault. Thus, I will look into using ADD_TO_LIBS in sysloc.in as you suggested and also look carefully at whether all the "default" logic boilerplate in configure.ac is really required. That will be 3rd on my PLplot ToDo list after finishing fortran examples 16-18 and companion fortran interface changes and doing comprehensive testing of the recent *DIR changes and your forthcoming changes for the configuration of the examples. 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: Rafael L. <rla...@us...> - 2004-01-01 17:20:12
|
* Alan W. Irwin <ai...@us...> [2003-12-31 12:59]: > I just realized the above logic actually works fine. > > grep CMD Makefile > CDINCCMD = > CDLIBCMD = -lcd > FREETYPEINCCMD = -I/usr/include/freetype2 > FREETYPELIBCMD = -lfreetype > GDINCCMD = > GDLIBCMD = -lgd -lpng -ljpeg -lz > ITCLINCCMD = -I/usr/include/tcl8.3/itcl-private/generic > ITCLLIBCMD = -litcl3.1 > ITKLIBCMD = -litk3.1 > JAVAINCCMD = -I/home/software/java/IBMJava2-14//include > -I/home/software/java/IBMJava2-14//include > TCLINCCMD = -I/usr/include/tcl8.3/tcl-private/generic > TCLLIBCMD = -ltcl8.3 > TKINCCMD = -I/usr/include/tcl8.3/tk-private/generic -I/usr/X11R6/include > TKLIBCMD = -ltk8.3 > > but the above logic occurs after sysloc.in so does not affect the sysloc.in > test that was producing the -Ldefault. But the library checks are done in sysloc.in and there is where the "-Ldefault" appears. This may be the source of the -lgd problem detected by Keon. At any rate, I think that the autoconf code in sysloc.in for library detection (gd, jpeg, zlib, etc) is highly non-standard and quite abstruse. It was generated by cut & paste editing instead of using autoconf macros to do the job. This makes the code pretty unmaintainable. I know, I know, the code works fine almost all the time, but I will see if I can improve the situation in the future. -- Rafael |
From: Alan W. I. <ai...@us...> - 2003-12-31 02:26:26
|
On 2003-12-30 19:22-0500 Koen van der Drift wrote: > On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote: > > > To make sure these issues are harmless, I suggest doing the following > > tcl/tk tests for PLplot: > > > > Try > > > > ./x01c -dev tk > > > > Does that interactive device (that depends on tcl/tk) work? > > No, I get this error: > > plFindCommand: cannot locate command: plserver > bin dir="/sw/bin" > > *** PLPLOT ERROR *** > Unable to fork server process > Program aborted > > /sw/bin/plserver does exist, though. What is the result of "which plserver". If that command finds plserver okay, then I believe the above issue is a showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we struggled with finding tcl/tk stuff we needed for PLplot on Linux until we got a kludge that shakily worked for that situation for -dev tk. What is really needed is to have some decent tcl/tk autotools macros to help PLplot find the tcl/tk stuff it needs. But I don't know of any that are compatible with the latest autotools so Mac OS X users may just have to wait to get access to -dev tk until that situation is rectified. > > > I get this error from the Mac OS X terminal's command line or from > within an X window. > > > > > Also in the _installed_ examples directory (or copy of it) try the > > ./plplot-test.sh script. > > That works, and results in plgrid.ps, plot.ps, pythondemos.ps, > tcldemos.ps, and the files for c and cc and cxx. Good, that is a pretty comprehensive test of the non-interactive file devices. Please remind us of the plplot version, the version of Mac OS X and the configure options you used for this success story. (There have been a lot of different Mac OS X threads recently.) From Rafael's post we probably know the "default" reason for your libgd problems that you also discussed in your post, and hopefully we will have a fix soon. 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: Koen v. d. D. <kvd...@ea...> - 2003-12-31 02:59:03
|
On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote: >> No, I get this error: >> >> plFindCommand: cannot locate command: plserver >> bin dir="/sw/bin" >> >> *** PLPLOT ERROR *** >> Unable to fork server process >> Program aborted >> >> /sw/bin/plserver does exist, though. > > What is the result of "which plserver". /sw/bin/plserver > But I don't know of any that are compatible > with the latest autotools so Mac OS X users may just have to wait to > get > access to -dev tk until that situation is rectified. I have absolutely no experiece with tcltk, so cannot help here :( >> That works, and results in plgrid.ps, plot.ps, pythondemos.ps, >> tcldemos.ps, and the files for c and cc and cxx. > > Good, that is a pretty comprehensive test of the non-interactive file > devices. Please remind us of the plplot version, the version of Mac OS > X and > the configure options you used for this success story. (There have > been a > lot of different Mac OS X threads recently.) This is on Mac OS X 10.3.2 and plplot-cvs-20031228 > > From Rafael's post we probably know the "default" reason for your libgd > problems that you also discussed in your post, and hopefully we will > have a > fix soon. Thanks again for all the help. It looks like the plplot fink package is shaping up and I will submit it to the fink project when the 5.2.2 release is out. Only scripting for octave and Fortran are not added yet - are these used by many users? - Koen. |
From: Alan W. I. <ai...@us...> - 2003-12-31 04:50:20
|
On 2003-12-30 21:58-0500 Koen van der Drift wrote: > On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote: > > Good, that is a pretty comprehensive test of the non-interactive file > > devices. Please remind us of the plplot version, the version of Mac OS > > X and > > the configure options you used for this success story. (There have > > been a > > lot of different Mac OS X threads recently.) > > This is on Mac OS X 10.3.2 and plplot-cvs-20031228 What were the configure options (other than prefix)? > > Thanks again for all the help. It looks like the plplot fink package is > shaping up and I will submit it to the fink project when the 5.2.2 > release is out. Only scripting for octave and Fortran are not added yet > - are these used by many users? Both the fortran and octave language interfaces are well worth having. For example, fortran dates back to 1954, and because it is such a simple, efficient language it is still the workhorse for many scientific numerical computations. However, the fortran interface to PLplot on Mac OS X is a sore point which I have been working on with Michel Peyrard. I am very close to the conclusion that the latest fink g77 (fortran compiler) is basically incompatible with the latest Apple gcc version (see discussion at http://www.chemistry.ucsc.edu/~wgscott/xtal/page2.html). I am hoping Michel (or you?) can find a g77 and gcc combination that are compatible (i.e., have the same version numbers) that I can recommend to our Mac OS X users. But if not, then we will just have to wait until fink gets its g77 packaging problem straightened out. Also, there are questions about the current fortran configuration even on Linux. If you do decide to try some fortran tests, please wait until Rafael and I sort out whether to use AC_F77_LIBRARY_LDFLAGS or not. I don't know anything about the fink packaging of octave (which is a free mostly Matlab compatible, high-level language). But if you have octave (2.1.x is necessary to work with PLplot now) installed it is certainly worth a try to see whether PLplot will work with it. (If octave is found on your system it will be enabled by default and plplot-test.sh will test it for the non-interactive case.) Thanks very much for your work exploring all the PLplot possibilities on Mac OS X and putting together a fink package for PLplot. 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: Koen v. d. D. <kvd...@ea...> - 2003-12-31 11:13:57
|
On Dec 30, 2003, at 11:50 PM, Alan W. Irwin wrote: > >> This is on Mac OS X 10.3.2 and plplot-cvs-20031228 > > What were the configure options (other than prefix)? --disable-dindrivers --with-double --disable-f77 > >> >> Thanks again for all the help. It looks like the plplot fink package >> is >> shaping up and I will submit it to the fink project when the 5.2.2 >> release is out. Only scripting for octave and Fortran are not added >> yet >> - are these used by many users? > > Both the fortran and octave language interfaces are well worth having. > I'll give it a shot next year and check the messages about fortran. Note that I have no experience and knowledge about both lnguages, so I cannot promise anything :). Another reason I am hesitating is that both fink packages are *huge*, so for some who only wants to use plplot with eg C, it will be overkill. - Koen. |
From: Rafael L. <lab...@ps...> - 2003-12-31 12:27:49
|
* Koen van der Drift <kvd...@ea...> [2003-12-31 06:12]: > Another reason I am hesitating is that both fink packages are *huge*, > so for some who only wants to use plplot with eg C, it will be > overkill. This is why I split the Debian packages: libplplot9 libplplot-dev plplot9-driver-xwin plplot9-driver-gnome plplot-tcl plplot-tcl-dev plplot9-driver-gd python-plplot octave-plplot plplot-doc For using the PLplot library with other programs (like PDL), users have just to have the libplplot9 package installed (1.1 M of size). For development with C, libplplot-dev (756 K) must also be installed. Of course, plplot-doc (3.8 M) is handful when doing development. Could you do something similar for Fink? -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2003-12-31 21:30:55
|
On Dec 31, 2003, at 7:23 AM, Rafael Laboissiere wrote: > This is why I split the Debian packages: > > libplplot9 > libplplot-dev > plplot9-driver-xwin > plplot9-driver-gnome > plplot-tcl > plplot-tcl-dev > plplot9-driver-gd > python-plplot > octave-plplot > plplot-doc > > For using the PLplot library with other programs (like PDL), users > have just > to have the libplplot9 package installed (1.1 M of size). For > development > with C, libplplot-dev (756 K) must also be installed. Of course, > plplot-doc > (3.8 M) is handful when doing development. > > Could you do something similar for Fink? > Yes - that should be possible. - Koen. |
From: Alan W. I. <ai...@us...> - 2003-12-31 20:04:33
|
On 2003-12-31 06:12-0500 Koen van der Drift wrote: > > On Dec 30, 2003, at 11:50 PM, Alan W. Irwin wrote: > > > > > >> This is on Mac OS X 10.3.2 and plplot-cvs-20031228 > > > > What were the configure options (other than prefix)? > > --disable-dindrivers --with-double --disable-f77 Thanks for that most useful report. I am going to take this opportunity to summarize the Mac OS X status. * Please note that the combination of --disable-dyndrivers and --disable-f77 works. In particular note the default shared libraries and python are working. (They did so in September with an older Mac OS X [10.1, I believe] and older PLplot cvs snapshot, but this is the first confirmation for Mac OS X 10.3 and a recent cvs snapshot.) (Note the spelling correction on --disable-dyndrivers, and also note that --with-double is default so you don't need to specify it.) * Once the get-drv-info bug is fixed for Mac OS X, then you will also be able to drop the --disable-dyndrivers limitation which will mean all Mac OS X PLplot executables will be considerably smaller. * The latest fink g77 3.4 fortran compiler is from the experimental development line of gcc compilers and is thus extremely unlikely to be compatible with gcc 3.3, the stable line of compilers from gcc including the tweaked version of gcc 3.3 from Apple that is used for fink development. See some discussion of this topic at http://www.chemistry.ucsc.edu/~wgscott/xtal/page2.html where it is noted that a lot of packages are now broken by the latest fink g77 "update" to version 3.4. * Also, apparently the recommended AC_F77_LIBRARY_LDFLAGS macro that we have tried recently for PLplot configuration is incompatible with gcc 3.3. I believe this is a bug in autoconf. * Until these last two external issues get straightened out we cannot make any forward progress in making the fortran interface to PLplot a smooth experience on Mac OS X. Thus, I recommend using --disable-f77 for now. However, if you want to try the fortran interface to PLplot on Mac OS X in an experimental way, Michel has posted some workarounds for the problems that currently occur. 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: Michel P. <Mic...@en...> - 2003-12-31 07:21:07
|
Koen, I was the one who posted a request for a fink package for plplot. I have now a working version thanks to the cvs tarball (altough there are still some problems) but I would definitely appreciate a fink package WITH fortran, and I am probably not alone. Fortran is still heavily used in the scientific community and the inteest of plplot is that it can display results of simulations while they are running. Michel %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Michel Peyrard, Professeur % Ph: +33 (0)4 7272 8374 % % Laboratoire de Physique % Fax: +33 (0)4 7272 8080 % % Ecole Normale Sup=E9rieure de Lyon % e-mail:Mic...@en... % % 46 all=E9e d'Italie % perso.ens-lyon.fr/michel.peyrard % % 69364 Lyon Cedex 07, France % (GPG key available on home page) % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% On Tue, 30 Dec 2003, Koen van der Drift wrote: > > On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote: > > >> No, I get this error: > >> > >> plFindCommand: cannot locate command: plserver > >> bin dir=3D"/sw/bin" > >> > >> *** PLPLOT ERROR *** > >> Unable to fork server process > >> Program aborted > >> > >> /sw/bin/plserver does exist, though. > > > > What is the result of "which plserver". > > /sw/bin/plserver > > > But I don't know of any that are compatible > > with the latest autotools so Mac OS X users may just have to wait to > > get > > access to -dev tk until that situation is rectified. > > I have absolutely no experiece with tcltk, so cannot help here :( > > >> That works, and results in plgrid.ps, plot.ps, pythondemos.ps, > >> tcldemos.ps, and the files for c and cc and cxx. > > > > Good, that is a pretty comprehensive test of the non-interactive file > > devices. Please remind us of the plplot version, the version of Mac OS > > X and > > the configure options you used for this success story. (There have > > been a > > lot of different Mac OS X threads recently.) > > This is on Mac OS X 10.3.2 and plplot-cvs-20031228 > > > > > > From Rafael's post we probably know the "default" reason for your libgd > > problems that you also discussed in your post, and hopefully we will > > have a > > fix soon. > > > Thanks again for all the help. It looks like the plplot fink package is > shaping up and I will submit it to the fink project when the 5.2.2 > release is out. Only scripting for octave and Fortran are not added yet > - are these used by many users? > > > - Koen. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Rafael L. <rla...@us...> - 2003-12-31 10:09:24
|
* Koen van der Drift <kvd...@ea...> [2003-12-30 21:58]: > Only scripting for octave and Fortran are not added yet - are these used by > many users? Just to echo Alan's words: Octave is an almost complete Matlab clone, even better in some aspects. The only area where Octave is lagging behind Matlab is exactly... graphics! This is one of the main reasons I got involved with PLplot. You will find lots of information on Octave in: http://www.octave.org http://octave.sf.net -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-01 12:41:47
|
On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote: > > If that command finds plserver okay, then I believe the above issue is > a > showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we > struggled with finding tcl/tk stuff we needed for PLplot on Linux > until we > got a kludge that shakily worked for that situation for -dev tk. This is probably a silly question, but maybe the command ./x01 -dev tk only works if issued from a tk window? If so, how do I get such a window in the first place? - Koen. |
From: Alan W. I. <ai...@us...> - 2004-01-01 16:56:17
|
On 2004-01-01 07:38-0500 Koen van der Drift wrote: > > On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote: > > > > > If that command finds plserver okay, then I believe the above issue is > > a > > showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we > > struggled with finding tcl/tk stuff we needed for PLplot on Linux > > until we > > got a kludge that shakily worked for that situation for -dev tk. > > > This is probably a silly question, but maybe the command ./x01 -dev tk > only works if issued from a tk window? If so, how do I get such a > window in the first place? No, it creates the necessary environment from the command line by calling plserver to do the heavy lifting. So this "device" is actually implemented in a quite complicated and therefore fragile (as I mentioned) way, but the results are worth having since they include all the power of what is available from plserver. To make this device available cross-platform in a robust way we are going to need some high-quality tcl/tk macros for autoconf to help PLplot find tcl/tk locations and capabilities that it needs. As a test of tcl/tk you could also try the new tk device -dev ntk which you also run from the command-line. It might work because my understanding is ntk device is implemented in a less complicated way than the tk device, but OTOH the ntk device capabilities have not been developed yet to the same level that is available with the tk device. 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 __________________________ |