From: Koen v. d. D. <kvd...@ea...> - 2004-01-10 01:59:18
|
Hi, To be sure that I didn't miss any dependencies for the fink package of plplot, I removed all installed packages from fink, and started to rebuild plplot (20040104 tarball). Compilation now stops with the following error: ... In file included from /sw/include/octave-2.1.50/octave/oct.h:31, from plplot_octave.cc:12: /sw/include/octave-2.1.50/octave/config.h:635:1: warning: "PACKAGE_VERSION" redefined In file included from plplot_octave_org.h:122, from plplot_octave.cc:8: ../../config.h:203:1: warning: this is the location of the previous definition g++ -bundle -bundle_loader /sw/bin/octave-2.1.50 -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd -L/sw/lib/octave-2.1.50 -loctave -lcruft -loctinterp -framework vecLib -L/sw/lib -ldfftw ld: warning -prebind has no effect with -bundle ld: warning can't open dynamic library: /sw/lib/libcsirocsa.0.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _csa_addpoints referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib _csa_approximate_points referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib _csa_calculatespline referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib _csa_create referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib _csa_destroy referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib make[4]: *** [plplot_octave.oct] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of (export failed, exit code 2 Failed: compiling plplot-5.2.1.cvs.20040104-1 failed It looks like the file /sw/lib/libcsirocsa.0.dylib cannot be found. This is of course true, because it hasn't been installed yet. I guess I missed this before, because plplot was already installed, I was just rebuilding it. Is this possible an error in the compile script or did I miss some setting for my fink package? thanks, - Koen. ps as you can see in the snippet - octave support is now also included! |
From: Alan W. I. <ai...@us...> - 2004-01-10 06:05:55
|
On 2004-01-09 20:59-0500 Koen van der Drift wrote: > g++ -bundle -bundle_loader /sw/bin/octave-2.1.50 -o plplot_octave.oct > plplot_octave.o -L../../src/.libs -lplplotd -L/sw/lib/octave-2.1.50 > -loctave -lcruft -loctinterp -framework vecLib -L/sw/lib -ldfftw > ld: warning -prebind has no effect with -bundle > ld: warning can't open dynamic library: /sw/lib/libcsirocsa.0.dylib > (checking for undefined symbols may be affected) (No such file or > directory, errno = 2) [...] > > It looks like the file /sw/lib/libcsirocsa.0.dylib cannot be found. > This is of course true, because it hasn't been installed yet. I guess I > missed this before, because plplot was already installed, I was just > rebuilding it. Is this possible an error in the compile script or did I > miss some setting for my fink package? I believe it is a cross-platform error in our configuration of the octave interface. The g++ link line above refers to -lplplotd, the PLplot library which in turn is linked against another one of our libraries called libcsirocsa. All is fine on Linux with ordinary non-libtool linking as above because the native Linux linking mechanism keeps track of such hierarchical linking, and you only have to specify the first library in the chain, libplplot in this case. For all our other interfaces besides the octave one, we build the interface with libtool which on a cross-platform basis does the same thing as in the ordinary (non-libtool) native Linux linking case. You only have to specify the first library in the chain, and libtool then refers to the *.la files to figure out the rest of the chain and do what is right for each platform. However, our octave interface is currently done differently and uses the mkoctfile command to build the interface. It has no way of getting the hierarchical linking information it needs directly (it does not access the *.la files recording such information) so it relies on the native linking mechanism to do it. That works on Linux, but obviously does not work on Mac OS X. There are two possible solutions I can see. * One alternative is to substantially modify the mkoctfile approach to link plplot_octave.oct above against everything libplplot is linked against. However, that very much depends on whether you are talking about the build tree libplplot or the installed version, whether you are using static libraries, shared libraries or both, and whether dynamic drivers are used or not. You would have to worry about libfreetype2, libcsirocsa, libcsironn, libqhull in all cases. And if you were not using dynamic drivers that makes a real mess because they are then embedded in libplplot and you would have to also optionally link against libraries required by those drivers. That includes libgd, libjpeg, libpng, zlib, X library, libcd, and tcl/tk libraries. So if you want to support all the different cases correctly in a cross-platform way this is going to be a lot of work. * Another approach which I feel is better would be to build our octave interface with libtool just like we do all the rest of our interfaces to PLplot. Once this approach was set up properly on Linux, then you are pretty much guaranteed to get all the linking details correct for all cases (build tree or install tree, static or dynamic libraries, dynamic drivers or not) for every platform right out of the box. That is the power of libtool, and I think we should use that power rather than continuing with the mkoctfile approach. If we do decide to go with the second alternative, I think the implementation would be fairly straightforward. For example, to get the required -I commands you need for libtool, you would simply execute mkoctfile -p INCFLAGS. On my system that command returns the following: -I/usr/include/octave-2.1.35 -I/usr/include/octave-2.1.35/octave -I/usr/include What libraries to mention to libtool may be a bit more complicated. On linux, mkoctfile -p SH_LDFLAGS returns only the string -shared, and indeed I notice that is the only "extra" link command used by mkoctfile for the Linux case. For Mac OS X the situation is more complicated and for example -L/sw/lib/octave-2.1.50 -loctave is mentioned above as part of the link line. So I would have to take the output from "mkoctfile -p SH_LDFLAGS" and filter it for -L and -l flags (which would return nothing on Linux and quite a bit more on Mac OS X) before using those library directory and library flags in conjunction with libtool. But that filtering should be completely straightforward using sed, and I think the result should work well on Linux and Mac OS X (and most/all other Unix platforms). Joao, you are pretty much our octave expert here. Should I try the libtool approach I have outlined above? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-10 15:18:03
|
On Jan 10, 2004, at 1:05 AM, Alan W. Irwin wrote: > If we do decide to go with the second alternative, I think the > implementation would be fairly straightforward. For example, to get > the > required -I commands you need for libtool, you would simply execute > mkoctfile -p INCFLAGS. On my system that command returns the > following: > > -I/usr/include/octave-2.1.35 -I/usr/include/octave-2.1.35/octave > -I/usr/include > > What libraries to mention to libtool may be a bit more complicated. On > linux, mkoctfile -p SH_LDFLAGS returns only the string -shared, and > indeed I > notice that is the only "extra" link command used by mkoctfile for the > Linux case. > For Mac OS X the situation is more complicated and for example > -L/sw/lib/octave-2.1.50 -loctave is mentioned above as part of the link > line. So I would have to take the output from "mkoctfile -p > SH_LDFLAGS" and > filter it for -L and -l flags (which would return nothing on Linux and > quite > a bit more on Mac OS X) before using those library directory and > library > flags in conjunction with libtool. But that filtering should be > completely > straightforward using sed, and I think the result should work well on > Linux > and Mac OS X (and most/all other Unix platforms). > Thanks for the explanation Alan. It's all pretty new to me (the nuts and bolts of compilers and linkers, I mean) so I think I have to read it a couple of times before I really understand it :) Is there something you want me to test to see if your solution works on my system? thanks, - Koen. |
From: Alan W. I. <ai...@us...> - 2004-01-10 16:11:15
|
On 2004-01-10 10:17-0500 Koen van der Drift wrote: > > On Jan 10, 2004, at 1:05 AM, Alan W. Irwin wrote: > > > If we do decide to go with the second alternative, I think the > > implementation would be fairly straightforward. [...] > > Thanks for the explanation Alan. It's all pretty new to me (the nuts > and bolts of compilers and linkers, I mean) so I think I have to read > it a couple of times before I really understand it :) > > Is there something you want me to test to see if your solution works on > my system? Yes, there is something you can do that will be useful at this stage (come to think of it). What is the output of mkoctfile -p INCFLAGS on your system? Same question for mkoctfile -p SH_LDFLAGS I would like my idea of using libtool and the output of the above two commands (suitably filtered in the case of "mkoctfile -p SH_LDFLAGS"), to be checked by at least one other developer (Joao is the obvious choice, and I hope he sends in the same two outputs for his OSF1 system if he has octave installed there). Assuming Joao can find no obvious problems with this approach, I think the implementation will be easy (one simple filter script to do) and soon after we will need your help again for testing that implementation. But for now, the two outputs requested above will be useful for Mac OS X systems. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ai...@us...> - 2004-01-10 17:32:21
|
On 2004-01-10 11:52-0500 Koen van der Drift wrote: > > On Jan 10, 2004, at 11:11 AM, Alan W. Irwin wrote: > > > Yes, there is something you can do that will be useful at this stage > > (come > > to think of it). > > > > What is the output of > > > > mkoctfile -p INCFLAGS > > -I/sw/include/octave-2.1.50 -I/sw/include/octave-2.1.50/octave > -I/sw/include Looks good. > > > > > > > on your system? > > > > Same question for > > > > mkoctfile -p SH_LDFLAGS > > > > > > -L/sw/lib > > However, /sw/lib/octave and /sw/lib/octave-2.1.50 also exist. > I don't understand that result, and I suspect there is another -p flag that should be used instead. To help me find what that is, could you please send to the list (as an attachment) your mkoctfile file? To find it on your system run the command "which mkoctfile". Thanks in advance.... 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-10 17:36:52
Attachments:
mkoctfile-2.1.50
|
On Jan 10, 2004, at 12:32 PM, Alan W. Irwin wrote: > I don't understand that result, and I suspect there is another -p flag > that > should be used instead. To help me find what that is, could you > please send > to the list (as an attachment) your mkoctfile file? To find it on your > system run the command "which mkoctfile". > it's attached. - Koen. |
From: Alan W. I. <ai...@us...> - 2004-01-10 06:39:24
|
On 2004-01-09 22:05-0800 Alan W. Irwin wrote: > [...]But that filtering should be completely > straightforward using sed, and I think the result should work well on Linux > and Mac OS X (and most/all other Unix platforms). Actually a sh script to do this turned out to be easier to implement than a sed approach. #!/bin/sh # # Parse the input line to echo all the -L and -l options in it. # This is meant to be used to process the results of mkoctfile -p SH_LDFLAGS # to pick up all the link line information that libtool needs to know. # OUT="" # Loop over command line args while test $ case $1 in -L*) OUT="$OUT $1" ;; -l*) OUT="$OUT $1" ;; esac shift done echo $OUT passing the link line generated by mkoctfile (given us by Koen) on MacOS X through this script I get the following result: -L/sw/lib/octave-2.1.50 -loctave -lcruft -loctinterp -L/sw/lib -ldfftw With the required library directories and libraries identified for all systems by "mkoctfile -p SH_LDFLAGS" filtered by the above script, and the required -I options given by "mkoctfile -p INCFLAGS", libtool should be able to do the rest. In sum I think this whole approach will be quite straighforward to implement in a short amount of time. Do you see any snags, Joao? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ai...@us...> - 2004-01-10 06:50:45
|
On 2004-01-09 22:39-0800 Alan W. Irwin wrote: > Do you see any snags, Joao? Actually, I do need help to implement the real filter script. The quick script I showed processed command-line arguments generated with `cat filename` as a proof of concept. Obviously that has to be turned into reading stdin and accumulating each white-space delimited piece that starts with -L or -l, but I believe that should be a straightforward change. Alternatively, if somebody wants to donate a 100-byte perl script to do the same thing, that would be great. Is there anything else I am missing? 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 __________________________ |