Menu
▾
▴
plplot-general
|
From: Joe C. <ch...@tr...> - 2006-09-08 22:39:22
|
Hello, I am writing an Open Source application using wxGTK-2.6.3 and plplot-5.6.1 on a Scientific Linux release 4.3 box with gcc v3.4.5 The app runs fine on that machine, but when I copy it to another linux box, along with the needed .so files, it aborts with the message: Unable to load driver: wxwidgets. *** PLPLOT ERROR *** Unable to load driver Program aborted I have copied the driver directory to the other machine, and placed it in a subdirectory of the libs directory where the .so files are located, and set the environment variable PLPLOT_DRV_DIR to that directory. What am I missing? Thanks in advance for any assistance. Joe Chuma TRIUMF |
|
From: Alan W. I. <ir...@be...> - 2006-09-09 01:23:40
|
On 2006-09-08 15:39-0700 Joe Chuma wrote: > Hello, > > I am writing an Open Source application using wxGTK-2.6.3 and > plplot-5.6.1 on a Scientific Linux release 4.3 box with gcc v3.4.5 > > The app runs fine on that machine, but when I copy it to another > linux box, along with the needed .so files, it aborts with > the message: > > Unable to load driver: wxwidgets. > > *** PLPLOT ERROR *** > Unable to load driver > Program aborted > > I have copied the driver directory to the other machine, and > placed it in a subdirectory of the libs directory where the > .so files are located, and set the environment variable > PLPLOT_DRV_DIR to that directory. What am I missing? I would advise building and installing PLplot from scratch on the second box rather than trying to copy bits and pieces from your first to your second box. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Werner S. <sm...@ia...> - 2006-09-09 11:21:59
|
Hi, there is maybe a library missing on the other Linux box (libltdl is needed for dynamic driver loading). As Alan said it would be best to compile plplot on the other LB as well. If not possible you could disable dynamic driver loading (therefore drivers are linked into the main plplot library) and you could also make a static plplot library - in both cases you don't need to care about driver loading at run time. This will not work for a c-program though only for a c++ program or if you use the c++ compiler, since the wxwidgets driver is c++. HTH, Werner Joe Chuma wrote: > Hello, > > I am writing an Open Source application using wxGTK-2.6.3 and > plplot-5.6.1 on a Scientific Linux release 4.3 box with gcc v3.4.5 > > The app runs fine on that machine, but when I copy it to another > linux box, along with the needed .so files, it aborts with > the message: > > Unable to load driver: wxwidgets. > > *** PLPLOT ERROR *** > Unable to load driver > Program aborted > > I have copied the driver directory to the other machine, and > placed it in a subdirectory of the libs directory where the > .so files are located, and set the environment variable > PLPLOT_DRV_DIR to that directory. What am I missing? > > Thanks in advance for any assistance. > > Joe Chuma > TRIUMF > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Werner S. <sm...@ia...> - 2006-09-11 08:26:31
|
Hi, another thing which came into my mind is, that you forgot to copy the wxwidgets library, since the wxwidgets driver obviously depends on it - but this is even more problematic, since the wxwidgets library depends on many other system libraries. But you can always check with the command "ldd" if there is any dependency on a library which is not fulfilled. HTH, Werner Werner Smekal wrote: > Hi, > > there is maybe a library missing on the other Linux box (libltdl is > needed for dynamic driver loading). As Alan said it would be best to > compile plplot on the other LB as well. If not possible you could > disable dynamic driver loading (therefore drivers are linked into the > main plplot library) and you could also make a static plplot library - > in both cases you don't need to care about driver loading at run time. > This will not work for a c-program though only for a c++ program or if > you use the c++ compiler, since the wxwidgets driver is c++. > > HTH, > Werner > > Joe Chuma wrote: >> Hello, >> >> I am writing an Open Source application using wxGTK-2.6.3 and >> plplot-5.6.1 on a Scientific Linux release 4.3 box with gcc v3.4.5 >> >> The app runs fine on that machine, but when I copy it to another >> linux box, along with the needed .so files, it aborts with >> the message: >> >> Unable to load driver: wxwidgets. >> >> *** PLPLOT ERROR *** >> Unable to load driver >> Program aborted >> >> I have copied the driver directory to the other machine, and >> placed it in a subdirectory of the libs directory where the >> .so files are located, and set the environment variable >> PLPLOT_DRV_DIR to that directory. What am I missing? >> >> Thanks in advance for any assistance. >> >> Joe Chuma >> TRIUMF >> >> >> >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Plplot-general mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-general > > -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Werner S. <sm...@ia...> - 2006-09-12 07:41:11
|
Hi Joe, are you using the plplot library within your wxWidgets application (in a widget)? Anyway, as far as I remember the discussions on the wxWidgets mailing list, they propose to use the static wxWidgets library for Linux in case you want to distribute your program (or you have to fiddle around with LD_LIBRARY_PATH to set the path to your copied shared wxWidgets library, but this should not be used other than debug purposes actually). You can also switch off a lot of libraries you don't need during the configure step to reduce dependencies (either like this --without-libtiff or like this --with-expat=builtin). If wxWidgets is static, plplot must also be static - so you first need to recompile/reconfigure wxWidgets to be static (--disable-shared). If this doesn't work (I'm not 100% sure about the automake build system of plplot) this should be possible with the new cmake build system which is already in cvs - a new improved wxwidgets driver will also be available soon. The option ENABLE_CXX_MIX allows to introduce the cpp wxWidgets driver into the c plplot library. HTH, Werner Joe Chuma wrote: > Werner Smekal wrote: >> Hi, >> >> there is maybe a library missing on the other Linux box (libltdl is >> needed for dynamic driver loading). As Alan said it would be best to >> compile plplot on the other LB as well. If not possible you could >> disable dynamic driver loading (therefore drivers are linked into the >> main plplot library) and you could also make a static plplot library - >> in both cases you don't need to care about driver loading at run time. >> This will not work for a c-program though only for a c++ program or if >> you use the c++ compiler, since the wxwidgets driver is c++. > > Thanks for the suggestions, but I am writing an application distributed > by SourceForge for use by the scientific community. It would be nice > to be able to distribute an executable, as well as the sources, so users > would not have to build their own copies of wxWidgets, PLplot, etc. > The wxWidgets driver in PLplot currently is only available as a dynamic > shareable image, so I can't link statically. The PLplot sources seem > to show it using the PLPLOT_DRV_DIR environment variable to find the > drivers' location, but it does not seem to work. Any assistance is > greatly appreciated. > > Joe Chuma > TRIUMF > > -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Alan W. I. <ir...@be...> - 2006-09-12 16:32:26
|
On 2006-09-12 09:40+0200 Werner Smekal wrote: > Hi Joe, > > are you using the plplot library within your wxWidgets application (in a > widget)? > > Anyway, as far as I remember the discussions on the wxWidgets mailing > list, they propose to use the static wxWidgets library for Linux in case > you want to distribute your program (or you have to fiddle around with > LD_LIBRARY_PATH to set the path to your copied shared wxWidgets library, > but this should not be used other than debug purposes actually). You can > also switch off a lot of libraries you don't need during the configure > step to reduce dependencies (either like this --without-libtiff or like > this --with-expat=builtin). > If wxWidgets is static, plplot must also be static - so you first need > to recompile/reconfigure wxWidgets to be static (--disable-shared). > If this doesn't work (I'm not 100% sure about the automake build system > of plplot) this should be possible with the new cmake build system which > is already in cvs - a new improved wxwidgets driver will also be > available soon. The option ENABLE_CXX_MIX allows to introduce the cpp > wxWidgets driver into the c plplot library. To clarify the situation, for the Unix case, our CBS follows the same rules as our ABS, i.e., the psttf and wxwidgets C++ device drivers are turned off whenever dynamic devices are disabled. The reason is that the driver object code becomes part of the core PLplot C library when dynamic drivers are disabled, and some Unix platforms cannot handle the resulting mix of C++ code from those particular device drivers and normal C code from the remainder of the devices and the PLplot core. (Note disabling shared libraries automatically disables dynamic drivers, but if shared libraries are enabled, then the user has the choice of enabling or disabling dynamic devices.) Our ABS system does not handle the windows case, but our CBS system does. For CBS on a windows platform we have found experimentally that you can mix the C++ device driver code into the C library so for that particular case we allow both psttf and wxwidgets regardless of whether dynamic devices are enabled or not. But for Unix our CBS is just as strict on this matter as our ABS. So from the above explanation, we are dealing with a fairly tangled thicket of Boolean logic, but there are practical reasons behind all of it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Joe C. <ch...@tr...> - 2006-09-13 17:11:24
|
Alan W. Irwin wrote: > On 2006-09-12 09:40+0200 Werner Smekal wrote: > >> Hi Joe, >> >> are you using the plplot library within your wxWidgets application (in a >> widget)? >> >> Anyway, as far as I remember the discussions on the wxWidgets mailing >> list, they propose to use the static wxWidgets library for Linux in case >> you want to distribute your program (or you have to fiddle around with >> LD_LIBRARY_PATH to set the path to your copied shared wxWidgets library, >> but this should not be used other than debug purposes actually). You can >> also switch off a lot of libraries you don't need during the configure >> step to reduce dependencies (either like this --without-libtiff or like >> this --with-expat=builtin). >> If wxWidgets is static, plplot must also be static - so you first need >> to recompile/reconfigure wxWidgets to be static (--disable-shared). >> If this doesn't work (I'm not 100% sure about the automake build system >> of plplot) this should be possible with the new cmake build system which >> is already in cvs - a new improved wxwidgets driver will also be >> available soon. The option ENABLE_CXX_MIX allows to introduce the cpp >> wxWidgets driver into the c plplot library. > > To clarify the situation, for the Unix case, our CBS follows the same rules > as our ABS, i.e., the psttf and wxwidgets C++ device drivers are turned off > whenever dynamic devices are disabled. The reason is that the driver > object > code becomes part of the core PLplot C library when dynamic drivers are > disabled, and some Unix platforms cannot handle the resulting mix of C++ > code from those particular device drivers and normal C code from the > remainder of the devices and the PLplot core. (Note disabling shared > libraries automatically disables dynamic drivers, but if shared libraries > are enabled, then the user has the choice of enabling or disabling dynamic > devices.) Our ABS system does not handle the windows case, but our CBS > system does. For CBS on a windows platform we have found experimentally > that you can mix the C++ device driver code into the C library so for that > particular case we allow both psttf and wxwidgets regardless of whether > dynamic devices are enabled or not. But for Unix our CBS is just as strict > on this matter as our ABS. > > So from the above explanation, we are dealing with a fairly tangled thicket > of Boolean logic, but there are practical reasons behind all of it. So, the answer is that if the plplot wxwidgets driver is used within an application, the plplot library must be installed on the target machine? There is no way to distribute a self-contained executable image of an application which uses the wxwidgets driver? There is no way to simply bundle the plplot .so files with the executable image and indicate their location through something like an environment variable? Building the plplot libs, with the wxwidgets driver, requires the target machine to also have the wxwidgets package already installed. So, an app which uses the plplot wxwidgets driver cannot be distributed as an executable image. All I wanted plplot for was its surface plotting capabilities, but this is a huge disadvantage and will force me to look elsewhere for less restrictive and more portable code. Joe Chuma TRIUMF |
|
From: Arjen M. <arj...@wl...> - 2006-09-14 06:46:06
|
Alan W. Irwin wrote >>So, an >>app which uses the plplot wxwidgets driver cannot be distributed as an >>executable image. >> >> > >That conclusion is incorrect. If you link your app correctly, and supply >all the required bits and pieces of PLplot, there should be no problems. > >The whole point of shared libraries and plug-ins is to keep logically >distinct things separate rather than putting all code into one giant >library. This approach actually minimizes the size of what you have to >distribute since you only have to include the bits and pieces of PLplot that >you need rather than everything. However, the trick is figuring out the >exact bits and pieces that you need (see below). > > You should regard the wxwidgets driver like any driver: most require support from external software. The exceptions are the PostScript driver and several others, but you can not usefully do anything with the output unless you have software and hardware to display PostScript files on the screen or print them on paper. In a very similar way any driver that displays the plot in a window on screen relies on system software that is already present, be that X Window or MicroSoft's Windows or whatever. You do not deliver that as part of your application. And you do not need to use wxwidgets, as there are plently of other device drivers available. Regards, Arjen |
|
From: Alan W. I. <ir...@be...> - 2006-09-13 18:39:34
|
On 2006-09-13 10:11-0700 Joe Chuma wrote: > So, the answer is that if the plplot wxwidgets driver is used within an > application, the plplot library must be installed on the target machine? Yes. > There is no way to distribute a self-contained executable image of an > application which uses the wxwidgets driver? No. As I explained, wxwidgets.so and libplplot.so normally must be separate since they are written in two different languages (C++ and C). > Building the plplot libs, with the wxwidgets driver, requires the target > machine to also have the wxwidgets package already installed. Yes. In fact, to use wxwidgets.so you must have the wxwidgets software package installed since all wxwidgets.so does is provide an interface between PLplot and the wxwidgets software package. > So, an > app which uses the plplot wxwidgets driver cannot be distributed as an > executable image. That conclusion is incorrect. If you link your app correctly, and supply all the required bits and pieces of PLplot, there should be no problems. The whole point of shared libraries and plug-ins is to keep logically distinct things separate rather than putting all code into one giant library. This approach actually minimizes the size of what you have to distribute since you only have to include the bits and pieces of PLplot that you need rather than everything. However, the trick is figuring out the exact bits and pieces that you need (see below). Your C app should link to the core PLplot library which supplies fundamental plotting routines such as the surface plots that you need. When your app asks for the wxwidgets device, then that core library dynamically loads the wxwidgets.so plug-in which supplies a PLplot interface to the wxwidgets library which your application can use with normal PLplot commands. So you only have to distribute the core PLplot library (consisting of the actual library and some additional support files) and wxwidgets.so, and your user has to have the wxwidgets package of software installed. As I explained at the start of this thread, this approach is not particularly easy to figure out. There will not be a lot of additional support files you have to distribute from your PLplot install on your original machine, but you will have to do some experimentation to see which files are actually required. The approach of using shared libraries and plug-ins is standard for most software these days. Therefore, you should familiarize yourself with this approach if you plan to distribute software. PLplot also provides the old-fashioned way of doing things; use static libraries and disable dynamic devices with all device driver code lumped into the core library. One disadvantage of that approach is your various apps become huge in size since they all contain duplicated code. More fundamentally, that old-fashioned approach does not work for wxwidgets.so since that device is written in C++ (as in the wxwidgets software package), and the PLplot core code is written in C. Mixing C and C++ code in the same library should be avoided because it can cause linking problems. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Geoffrey F. <fu...@li...> - 2006-09-13 22:06:18
|
Alan W. Irwin writes: > PLplot also provides the old-fashioned way of doing things; use static > libraries and disable dynamic devices with all device driver code lumped > into the core library. One disadvantage of that approach is your various > apps become huge in size since they all contain duplicated code. More > fundamentally, that old-fashioned approach does not work for wxwidgets.so > since that device is written in C++ (as in the wxwidgets software package), > and the PLplot core code is written in C. Mixing C and C++ code in the same > library should be avoided because it can cause linking problems. That's only for shared libs where there are system differences that make it thorny. For static linkage, you just have to ensure that the final application link step is done with C++. |
|
From: Werner S. <sm...@ia...> - 2006-09-14 10:05:18
|
Hi, I'm not sure, but I think Joe uses the plplot library and the wxwidgets driver within his wxWidgets application. If you want to distribute this application on Linux (and it should run on many different Linux distributions), you have to compile wxWidgets as a static library - this is what wxWidgets developers recommend. Than you also have to configure and compile plplot as static and mix c and c++ in the library - but this should be no problem for you, since your wxWidgets application is c++ anyway. It's possible to configure everything so that it uses e.g. the wxWidgets library provided by the distribution, but than it will only run on this distribution, since the wxWidgets library on Linux has many dependencies and you'll run into trouble very soon, i.e. on any other distribution. So, if you have a wxWidgets application - compile the libraries as static libraries and everything should be ok. This is far from perfect (shared would be better), but in the moment this is the way I would recommend (because of the many different Linux distributions). Werner Btw: Compile everything on a rather old Linux distribution (redhat 8.0 or 9.0) - than you'll maximize the number of Linux distribution your app will run on. >> That conclusion is incorrect. If you link your app correctly, and supply >> all the required bits and pieces of PLplot, there should be no problems. >> >> The whole point of shared libraries and plug-ins is to keep logically >> distinct things separate rather than putting all code into one giant >> library. This approach actually minimizes the size of what you have to >> distribute since you only have to include the bits and pieces of PLplot that >> you need rather than everything. However, the trick is figuring out the >> exact bits and pieces that you need (see below). >> > You should regard the wxwidgets driver like any driver: most require > support from > external software. The exceptions are the PostScript driver and several > others, but > you can not usefully do anything with the output unless you have > software and > hardware to display PostScript files on the screen or print them on paper. > > In a very similar way any driver that displays the plot in a window on > screen relies > on system software that is already present, be that X Window or > MicroSoft's Windows > or whatever. You do not deliver that as part of your application. And > you do not need > to use wxwidgets, as there are plently of other device drivers available. > > Regards, > > Arjen > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Joe C. <ch...@tr...> - 2006-09-15 17:57:50
|
Werner Smekal wrote: > Hi, > > I'm not sure, but I think Joe uses the plplot library and the wxwidgets > driver within his wxWidgets application. If you want to distribute this > application on Linux (and it should run on many different Linux > distributions), you have to compile wxWidgets as a static library - this > is what wxWidgets developers recommend. Than you also have to configure > and compile plplot as static and mix c and c++ in the library - but this > should be no problem for you, since your wxWidgets application is c++ > anyway. First, thank you (and others who have responded) for the assistance. Yes, my application, called extrema, is derived from a previous command driven app named physica. Physica has been in use at most physics labs around the world since 1993, and is mature software which started life on VAX/VMS and I have ported to alphaVMS, HP-UX, OSF, OSX, SGI/IRIX, SUNOS/SOLARIS, and Linux. See http://trshare.triumf.ca/~chuma/physica/homepage.html for info on physica. Extrema uses the wxWidgets package for the widgets and for the graphics, but it already has well developed graph plotting abilities. One feature that extrema is missing is 2D surface plots, and when I discovered PLplot's surface plotting capabilities, together with a simple interface to wxWidgets using wxDC's, it looked like a perfect fit. Until I tried running extrema on another Linux box. Without PLplot, extrema runs fine on other Linux boxes. I simply distribute the .so files with the executable and run the app from a shell script, setting LD_LIBRARY_PATH to the libs directory. I don't want the end user to be forced to install anything as root, since in many cases, they will not have that privilege. The wxWidgets .so files created under Scientific Linux 4.3 work fine under Red Hat 9. Extrema also works fine when wxWidgets is created statically, but I still have to distribute a few .so files from the pango, cairo and gtk packages. Anyway, everything works fine until I put PLplot into the mix. I am still confused by what you say above. Making static wxWidgets libs is no problem, but PLplot refuses to make a static wxwidgets driver. According to Alan Irwin: "To clarify the situation, for the Unix case, our CBS follows the same rules as our ABS, i.e., the psttf and wxwidgets C++ device drivers are turned off whenever dynamic devices are disabled." When I use the --disable-dyndrivers --disable-shared --enable-static flags with PLplot configure, the wxwidgets driver is not built. Are you saying that I must modify the configure/makefile structure in PLplot in order to get a static wxwidgets driver? > It's possible to configure everything so that it uses e.g. the wxWidgets > library provided by the distribution, but than it will only run on this > distribution, since the wxWidgets library on Linux has many dependencies > and you'll run into trouble very soon, i.e. on any other distribution. In my experience, I have not had much trouble distributing software for Linux. Programs built under RedHat 9 seemed to work fine under many other Linux distributions. When the kernel was upgraded to v2.6, most of my apps needed to be rebuilt, but that was not a problem. I just distribute 2 versions. Scientific Linux apps seem to run fine on most other Linux distributions, or is it just that most people in physics labs use the same Linux? > So, if you have a wxWidgets application - compile the libraries as > static libraries and everything should be ok. This is far from perfect > (shared would be better), but in the moment this is the way I would > recommend (because of the many different Linux distributions). If I could build PLplot with the wxwidgets driver as static libs, that would be great. If you can tell me how to do it, that would also be great, and I would appreciate it enormously. If I am simply missing something obvious, please let me know. Joe Chuma TRIUMF Canada's National Laboratory for Particle and Nuclear Physics |
|
From: Werner S. <sm...@ia...> - 2006-09-17 16:19:25
|
Hi Joe, > See > http://trshare.triumf.ca/~chuma/physica/homepage.html for info on > physica. Interesting, will have definitely a try. Overall, you run into a problem in the Linux world - how to distribute a Linux program, if you don't use the usual channels (rpm, deb, etc.). Since I'll run into this issue sooner or later, since I'm also trying to use plplot in my wxwidgets application. Anyway, two possibilities. shared plplot library: you can try the following: set the install directory other than /usr/local. (configure --prefix=/home/user/plplot_local) than you know exactly what files plplot installed and can even copy the whole directory. I would also suggest to turn off all drivers you don't need - this would minimize the dependencies. And you can do also the same for the wxwidgets library - install it in a own directory (--prefix=wxGTK_local) and turn off everything you don't need (--with-expat=false, etc). You get two directories which you can copy and set LD_LIBRARY_PATH accordingly. Mind though, that this is not good practice - since LD_LIBRARY_PATH is only for debugging purposes and not to use for installing executables. Anyway, you could also use the same directory for wxwidgets and plplot, so that everything is installed in the same directory and copy this to the extrema distribution. Also, you can use the command ldd on an executable or library, to find out, from which libraries it depends, and also shows if this library is not available on the system. This shouls help you a lot. It's also possible that you have the library, but the wrong version, which also might not work. > also works fine when wxWidgets is created statically, but I still have > to distribute a few .so files from the pango, cairo and gtk packages. > Anyway, everything works fine until I put PLplot into the mix. pango, cairo and gtk should definitely not distributed. This is really not a good idea, this libraries must be provided by the distribution, they are really basic. Ask the user to install this packages before he tries to start extrema. > I am still confused by what you say above. Making static wxWidgets libs > is no problem, but PLplot refuses to make a static wxwidgets driver. > According to Alan Irwin: "To clarify the situation, for the Unix case, > our CBS follows the same rules as our ABS, i.e., the psttf and wxwidgets > C++ device drivers are turned off whenever dynamic devices are > disabled." When I use the --disable-dyndrivers --disable-shared > --enable-static flags with PLplot configure, the wxwidgets driver is not > built. Are you saying that I must modify the configure/makefile > structure in PLplot in order to get a static wxwidgets driver? static plplot library: This could be possible for the configure case, but this can be overidden in cvs, where we use the new CMake Build System. You would need to check out from cvs the new sources (the wxwidgets driver) is also quite new and together with cmake you could compile plplot static with the wxwidgets static library. > In my experience, I have not had much trouble distributing software > for Linux. Programs built under RedHat 9 seemed to work fine under > many other Linux distributions. When the kernel was upgraded to v2.6, > most of my apps needed to be rebuilt, but that was not a problem. I > just distribute 2 versions. Scientific Linux apps seem to run fine > on most other Linux distributions, or is it just that most people in > physics labs use the same Linux? I don't use it :) I didn't even know it, but I'll have a look. Anyway, Redhat 9 is old enough, that apps built on this distribution will run on nearly all distr. but new enough, that you can compile anything on it. > If I could build PLplot with the wxwidgets driver as static libs, that > would be great. If you can tell me how to do it, that would also be > great, and I would appreciate it enormously. If I am simply missing > something obvious, please let me know. Could you first try the shared library solution with the directories, ldd and so on. If this doesn't work, than I write a short summary how to get the new sources from cvs and build a static library. Werner > > Joe Chuma > TRIUMF > Canada's National Laboratory for Particle and Nuclear Physics -- Dipl. Ing. Werner Smekal Vienna University of Technology |
|
From: Joe C. <ch...@tr...> - 2006-09-18 17:57:00
|
Werner Smekal wrote: > Hi Joe, > > shared plplot library: > you can try the following: set the install directory other than /usr/local. > (configure --prefix=/home/user/plplot_local) than you know exactly what files > plplot installed and can even copy the whole directory. I would also suggest > to turn off all drivers you don't need - this would minimize the > dependencies. And you can do also the same for the wxwidgets library - > install it in a own directory (--prefix=wxGTK_local) and turn off everything > you don't need (--with-expat=false, etc). > You get two directories which you can copy and set LD_LIBRARY_PATH > accordingly. Mind though, that this is not good practice - since > LD_LIBRARY_PATH is only for debugging purposes and not to use for installing > executables. Anyway, you could also use the same directory for wxwidgets and > plplot, so that everything is installed in the same directory and copy this > to the extrema distribution. Also, you can use the command ldd on an > executable or library, to find out, from which libraries it depends, and also > shows if this library is not available on the system. This shouls help you a > lot. It's also possible that you have the library, but the wrong version, > which also might not work. I have already tried this, but just to be sure, I did it from scratch again. No luck. The extrema program runs fine on my machine but when I copy it to another machine and try to use the surface plotting it comes back with *** PLPLOT ERROR *** plInitDispatchTable: Could not open drivers directory, aborting operation. Requested device wxwidgets not available Interestingly, when I try ldd on extrema, the wxwidgets.so driver lib is not listed ??? >> also works fine when wxWidgets is created statically, but I still have >> to distribute a few .so files from the pango, cairo and gtk packages. >> Anyway, everything works fine until I put PLplot into the mix. > > pango, cairo and gtk should definitely not distributed. This is really not a > good idea, this libraries must be provided by the distribution, they are > really basic. Ask the user to install this packages before he tries to start > extrema. I disagree. So far, except for PLplot, extrema works fine with the .so files that it needs put into a subdirectory of extrema, and the extrema program is run from a shell script, which sets LD_LIBRARY_PATH to that subdirectory before running the executable. I don't want to force users of extrema to install multiple packages that are peripheral to extrema. Many users will not have root privilege anyway, so what other choice is there? >> If I could build PLplot with the wxwidgets driver as static libs, that >> would be great. If you can tell me how to do it, that would also be >> great, and I would appreciate it enormously. If I am simply missing >> something obvious, please let me know. > > Could you first try the shared library solution with the directories, ldd and > so on. If this doesn't work, than I write a short summary how to get the new > sources from cvs and build a static library. I can't get the shared lib solution to work. If there is a static solution, I would be very grateful to be shown the details. Joe Chuma TRIUMF Canada's National Laboratory for Particle and Nuclear Physics |
|
From: Alan W. I. <ir...@be...> - 2006-09-18 19:56:29
|
On 2006-09-18 10:56-0700 Joe Chuma wrote: > I can't get the shared lib solution to work. If there is a static > solution, I would be very grateful to be shown the details. Our old Autotools Build System (ABS, which you are currently using) does not allow this. However, we also have a new much more flexible CMake Build System (CBS) that has been essentially completed for Linux (and which is still being worked on to implement complete builds of PLplot on Mac OS X and windows). Currently our CBS just follows our old ABS and disallow wxwidgets for the static case. However, I just came up with an idea about a change to our CBS that should make a static wxwidgets device work without mixing C and C++ code in the same library. The gist is when dynamic devices (plug-ins) are disabled, then two additional separate libraries (one for C driver code and one for C++ driver code) are made and our core library is linked to those two additional libraries. I generally like this idea because it means device driver code never gets into our core C library under any circumstances. Also, that linking should automatically be the desired static linking if you generally disable shared libraries for the PLplot build. The change means some CMake configuration reorganization so it may take a while (a day or so) to implement and test it. Joe, once I have done that, I will get back to you with the details so you can try this proposed CBS-based static linking for the wxwidgets device for yourself. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Joe C. <ch...@tr...> - 2006-09-18 21:43:45
|
Alan W. Irwin wrote: [snip] > > The change means some CMake configuration reorganization so it may take a > while (a day or so) to implement and test it. Joe, once I have done that, I > will get back to you with the details so you can try this proposed > CBS-based static linking for the wxwidgets device for yourself. Thank you very much. Joe Chuma TRIUMF Canada's National Laboratory for Particle and Nuclear Physics |
|
From: Alan W. I. <ir...@be...> - 2006-09-22 01:45:26
|
On 2006-09-18 12:48-0700 Alan W. Irwin wrote: > [...] The gist is when dynamic devices (plug-ins) are disabled, > then two additional separate libraries (one for C driver code and one for > C++ driver code) are made and our core library is linked to those two > additional libraries. This turned out to be a crummy idea. For the technical reasons behind that see my recent post to the plplot-devel list. However, that same post details how I tried the only other alternative (mixing C++ and C object code in the same library), and that apparently works on Linux (and maybe all other systems as well?). The current status is the CVS version of PLplot should give a static build of PLplot libraries (including the C++ wxwidgets and psttf devices) that passes all build-tree tests, but there is still a minor problem (library ordering issue) for the install tree tests which I will deal with tomorrow. Note, this PLplot "static build" is still not what Joe wants since even though the PLplot libraries are all statically linked together for this case, the external linking is still shared. I think the solution to making even the external linking shared is simply to impose the -Bstatic link option on top of the static PLplot build (once that completely works), but I haven't tried that yet, and I am sure there will be minor but time-consuming issues to sort out. Joe, you have come up with an interesting problem that now has me hooked, but it will probably be next week before I can come up with the definitive answer. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Joe C. <ch...@tr...> - 2006-09-22 15:53:46
|
Alan W. Irwin wrote: > On 2006-09-18 12:48-0700 Alan W. Irwin wrote: > > Joe, you have come up with an interesting problem that now has me > hooked, but it will probably be next week before I can come up with > the definitive answer. Thank you. I appreciate all the work you and others are putting into this problem. Joe Chuma TRIUMF Canada's National Laboratory for Particle and Nuclear Physics |
|
From: Alan W. I. <ir...@be...> - 2006-09-23 15:58:19
|
On 2006-09-21 18:44-0700 Alan W. Irwin wrote: > The current status is the CVS version of PLplot should give a static build > of PLplot libraries (including the C++ wxwidgets and psttf devices) that > passes all build-tree tests, but there is still a minor problem (library > ordering issue) for the install tree tests which I will deal with tomorrow. That problem is now sorted out for our new CBS. > > Note, this PLplot "static build" is still not what Joe wants since even > though the PLplot libraries are all statically linked together for this > case, the external linking is still shared. I think the solution to making > even the external linking shared is simply to impose the -Bstatic link > option on top of the static PLplot build (once that completely works), but I > haven't tried that yet, and I am sure there will be minor but time-consuming > issues to sort out. It turned out there were a lot of those, but I finally got a completely static build (with our new CBS) of one of the installed examples to work with the wxwidgets device driver. So Joe, here is the cookbook you should follow if you want a completely static build (no external library dependencies at all) of an executable that uses our plplot library (with embedded wxwidgets device and static linking to all the wxwidgets related libraries). If there is any part of the cookbook you do not understand, contact me off list. (1) Build a static version of wxwidgets. I don't think any distribution does that because there is a choice of static or shared, but apparently not both. Certainly, Debian and derivative like Ubuntu do not provide a static version of the wxwidgets libraries. I used wxGTK-2.6.3.tar.gz from SourceForge, and did their recommended out-of-source build using --disable-shared (which is their option for a static build). I also did a shared build as well because that is what I normally use, but I used a unique build tree and installation prefix for that so the shared and static results could not clash with each other. (2) Build PLplot with our new CBS. On your Linux build system follow the general Unix directions on our wiki (http://www.miscdebris.net/plplot_wiki). (Those instructions include downloading and building the latest version of cmake. That is currently 2.4.3. Don't use a lower version than that.) (2a) Preparation for the build using CMake. The wiki discusses helping cmake to find system resources. In my case I installed the above static wxwidgets package with a unique prefix of /usr/local/wxwidgets. Thus, I had to set PATH="/usr/local/wxwidgets/bin:"$PATH That allowed cmake to find the correct (static) version of wx-config and bootstrap all wxwidgets information from there. Here is the cmake command-line I used to pare everything down to a minimal PLplot system with one (wxwidgets) device: cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake \ -DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_cxx=OFF -DENABLE_f77=OFF \ -DENABLEf95=OFF -DENABLE_python=OFF -DENABLE_java=OFF -DENABLE_tcl=OFF \ -DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DBUILD_SHARED_LIBS=OFF \ ../plplot_cmake >& cmake.out You will undoubtedly want to use your own name for the installation prefix directory location and for plplot_cmake (a freshly checked out PLplot source tree from SourceForge). The rest of your cmake options should be identical with those above. Those options assure verbose make output (including all the compiler commands), turn off all language interfaces to our core C library, turn off all devices other than wxwidgets, and build plplot internally with static libraries. (2b) The build. Stay in the separate build tree you prepared with the above cmake command and invoke make >& make.out You will find it doesn't work because you are mixing C and C++ code (including the static wxwidgets library code as well as the wxwidgets PLplot device code) into all executables you build that refer to the C++ wxwidgets device. We only have one such executable (an executable called plrender). One method of beating the linking issue is to find the exact gcc command that did not work from the above make.out file, and replace gcc with g++ to get plrender linked properly for this special case of a static wxwidgets library. However, for your minimal needs you don't really need plrender so just touch the appropriate plrender file and proceed with make again to finish the build. (2c) The install. Stay in the same directory and invoke make install >& make_install.out Again, there is trouble with plrender, but you solve it the same way. "touch" is easier than invoking an exact g++ command. However, be sure to touch plrender in the correct directory given by make_install.out rather than the different directory where you touched plrender in (2b) above. Do "make install" after the touch to finish the install. Here are the essential installation results you should get from the above steps. cd /home/software/plplot_cvs/installcmake find -type f .... ./share/plplot5.6.1/plstnd5.fnt ./share/plplot5.6.1/plxtnd5.fnt .... ./share/plplot5.6.1/examples/Makefile ./share/plplot5.6.1/examples/c/plcdemos.h ./share/plplot5.6.1/examples/c/x01c.c ./share/plplot5.6.1/examples/c/Makefile .... ./lib/libcsirocsa.a ./lib/libcsironn.a ./lib/libplplotd.a ./lib/pkgconfig/plplotd.pc .... ./include/plplot/plplot.h + many more essential PLplot headers. (2d) Build the x01c example for static PLplot and wxwidgets libraries, but with everything else shared. cd /tmp cp -a /home/software/plplot_cvs/installcmake/share/plplot5.6.1/examples . cd examples/c make x01c >& make_x01c.out Again it won't work because of C/C++ linking issues and this time really do replace gcc with g++ to fix the problem. Note, this result does use the static PLPlot libraries (and you should check that ./x01c -dev wxwidgets gives good results) but we need one more step to make that x01c executable completely static. (2e) Build a completely static x01c example. The above command for (2d) is transformed to a completely static build with the -static gcc option. (Also, you don't need rpath since that is not relevant for a completly static build). Also, you have to add some libraries. Static linking must mention all the non-system libraries in the correct order and in general you cannot be as sloppy about libraries as in the shared case. The result is as follows: software@chickadee> g++ x01c.c -o x01c_static -static \ `PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig pkg-config --cflags --libs plplotd` \ -lX11 -lfontconfig -lXcursor -lXrender \ -lXext -lXft -lXrandr -lfreetype -lfontconfig -lX11 -lXi -lexpat -lXrender \ -lpangoft2-1.0 2>&1 |grep undefined |sort |uniq|wc -l 0 Note, all the required libraries that are listed out with the pkg-config command supplemented by the trailing -l options must have the *.a static form of library installed. It was at this stage I discovered I would have to build my own static version of the wxwidgets library since Ubuntu (and Debian) do no supply the static version. It's possible you will have similar trouble with the other required libraries as well. The solution is usually to install -devel versions of library packages. I used the grep undefined trick to keep track of all the undefined symbols you get with static linking if you don't take care to specify all libraries The wx-config result for wxwidgets (which is what our CBS uses to configure the above pkg-config command) is good enough for shared linking, but doesn't cut the mustard for static linking which is why I had to specify all those additional libraries with the above -l options. You also have to be careful of static library order which is why some of those -l options are repeated. The 0 at the end showed there were (finally after several hours effort to correlate every undefined symbol with a library using google searches and sometimes guesses) no undefined symbols in the result. (3) Results: Here is the size of the result: software@chickadee> ls -lh x01c_static -rwxr-xr-x 1 software software 12M Sep 22 22:38 x01c_static* (I was actually expecting bigger so I am pleasantly surprised by that.) ldd confirms the resulting x01c_static is completely static with no dependencies on libraries. ./x01c_static gives the same results as the shared version (x01c built in step (2d) You must distribute the Hershey fonts with your application (plstnd5.fnt and plxtnd5.fnt from above). The location of those fonts can be specified with the PLPLOT_LIB environment variable and if that is not specified or that location does not contain the Hershey fonts, then it falls back to the hard-coded install location, $prefix/share/plplot5.6.1 on the build box, see above. Thus, your users will probably have to set PLPLOT_LIB since the hard-coded location is unlikely to be relevant on their machine. The above fonts are only 65K so it is not going to be onerous for you to distribute them in addition to the large executable that is obtained from a static build. Note, one downside of the Hershey fonts are the resulting characters are crude (completely unhinted) for screen display. Fortunatley, the wxwidgets device can also use a high-quality font alternative. I have confirmed that alternative font system works well with ./x01c_static, but you should cross that bridge when you come to it. For now, please concentrate on getting the static x01c example built and working with the default Hershey fonts following the instructions above. This has been an interesting project, but I am also glad to be done with it. For a while there I thought I was in a time warp to the early 80's when every developer had to contend with static linking library order problems and trying to figure out which undefined symbol came from what library. In those days you looked everything up in a large room completely filled with computer manuals. Now it is significantly easier with google, but still difficult. Good luck in mimicking my completely static build result. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Jerry <lan...@qw...> - 2006-09-15 21:37:09
|
On Sep 15, 2006, at 10:56 AM, Joe Chuma wrote: > and is mature software which started life > on VAX/VMS and I have ported to alphaVMS, HP-UX, OSF, OSX, SGI/IRIX, > SUNOS/SOLARIS, and Linux. The web site could use a bit of updating wrt mentioning OS X ;). Jerry |
|
From: Joe C. <ch...@tr...> - 2006-09-15 21:46:49
|
Jerry wrote: > On Sep 15, 2006, at 10:56 AM, Joe Chuma wrote: > >> and is mature software which started life >> on VAX/VMS and I have ported to alphaVMS, HP-UX, OSF, OSX, SGI/IRIX, >> SUNOS/SOLARIS, and Linux. > > The web site could use a bit of updating wrt mentioning OS X ;). > > Jerry The web site could use a bit of updating wrt just about everything, but who has time for documentation? If you are actually interested in the OS X version of physica, you can get it from ftp://csftp.triumf.ca/pub/CompServ/physica/osx/physica-v2.81-osx10.3.9.tar.gz after looking at ftp://csftp.triumf.ca/pub/CompServ/physica/osx/aaaread-me.txt Joe Chuma TRIUMF Canada's National Laboratory for Particle and Nuclear Physics |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X