From: Koen v. d. D. <kvd...@ea...> - 2004-01-16 03:01:50
|
On Jan 15, 2004, at 9:49 PM, Alan W. Irwin wrote: > What happens if you start fresh and remove that -lcrt2.o, i.e. > > export FLIBS='-L%p/lib -lfrtbegin -lSystem' > > BTW, I am curious what the -L%p/lib does. Does %p stand for the > prefix you > use in your fink build script? You also asked about the order of the > -L and > -l options. I believe those are correct the way you have them. The > usual > rule is -L/library_path -llibrary. -L should point to a directory, > and the > following -l options describe the libraries by name that are required > from > that directory to do a proper link. > I have no access to my Mac right now, I'll try that later. And yes, the %p is used by fink, and expands to /sw. I just stole the export line from another fink package that uses octave (I think it is version 2.1.50). - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-16 08:53:22
|
* Alan W. Irwin <ir...@be...> [2004-01-15 18:49]: > I made an educated guess about what the problem was, Rafael did a nice > implementation that beat out my own way of solving the problem we thought > we had, and these good reports are our first indication that the inferred > problem is now fixed. It is hair-raising to work at one remove like this; > I am quite relieved by these good reports and I am sure Rafael is as well. Yes, of course, in particular because my solution was so simple (just four lines changed in bindings/octave/Makefile.am) and avoided the terrible libtool hijack, with all the nasty consequences it generated. At any rate, remember that my mkoctfile-based solution is also libtool-based, since the get-dependency-libs.sh script parses the .la file. This way, we get the best of both worlds. > Rafael, with two good octave linking reports do you agree it is now time to > (ceremoniously, I guess...:-)) pull all the remnants of my alternative > approach from cvs? Yes, please. Removal of cruft is always welcomed. > > but dyndrivers need to be disabled. > > Per reported that as well. But I don't think we changed anything in this > area since your last time you reported dyndrivers worked. Could you give > specific symptoms in case it is something introduced by Rafael's octave > linking fix? An easy way to test this is to configure --enable-dyndrivers --disable-octave and to see if the problem persists. Anyone, please? > > g++ x21.cc -o x21 `plplot-config --cflags --libs --with-c++` > > ld: warning -L: directory name > > (/Volumes/MoreStuff/.src/gd2-2.0.12-13/gd-2.0.12/.libs) does not exist > > I don't think this warning should be of any concern. Yes, but it is annoying. I suspect that plplot-config is not doing its job correctly here. Could a MacOS X user please send to us the output of plplot-config --cflags --libs --with-c++ I would also be interested in knowing the result of pkg-config on MacOS X. Of course, the pkg-config package will be needed and PLplot has to be configured --with-pkg-config. I am interested in the output of the following command: pkg-config --cflags --libs plplotd-c++ Googling quickly the web, I conclude that pkg-config must be available in Fink (see, e.g., http://www.go-mono.org/tutorial/installation/macosx.html) -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-16 23:44:56
|
On Jan 16, 2004, at 3:52 AM, Rafael Laboissiere wrote: > An easy way to test this is to configure --enable-dyndrivers > --disable-octave and to see if the problem persists. Anyone, please? They seem to be mutually exclusive. Here's the error I get when both are enabled: ... if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I/usr/X11R6/include/freetype2 -I../libltdl -I/sw/include -I../libltdl -Wno-long-double -MT get_drv_info-get-drv-info.o -MD -MP -MF ".deps/get_drv_info-get-drv-info.Tpo" \ -c -o get_drv_info-get-drv-info.o `test -f 'get-drv-info.c' || echo './'`get-drv-info.c; \ then mv -f ".deps/get_drv_info-get-drv-info.Tpo" ".deps/get_drv_info-get-drv-info.Po"; \ else rm -f ".deps/get_drv_info-get-drv-info.Tpo"; exit 1; \ fi /bin/sh ../libtool --mode=link gcc -Wno-long-double -L/sw/lib -o get-drv-info get_drv_info-get-drv-info.o ../libltdl/libltdlc.la gcc -Wno-long-double -o get-drv-info get_drv_info-get-drv-info.o -L/sw/lib ../libltdl/.libs/libltdlc.a -ldl ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc ltdl.c:2460: failed assertion `dirname' make[2]: *** [dg300.rc] Error 134 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of (export failed, exit code 2 Failed: compiling plplot-5.2.1.cvs.20040115-11 failed But, if plplot is already installed (when I don't start from scratch), I don't get the error, and compilation finishes! > Yes, but it is annoying. I suspect that plplot-config is not doing > its job > correctly here. Could a MacOS X user please send to us the output of > > plplot-config --cflags --libs --with-c++ ModusOperandi:/sw/fink/dists/local/main/finkinfo koen$ plplot-config --cflags --libs plplotd-c++ -I/sw/include/plplot -L/sw/lib /sw/lib/libplplotd.dylib -L/usr/X11R6/lib /sw/lib/libcsirocsa.dylib /sw/lib/libcsironn.dylib -lqhull /sw/lib/libgd.dylib -L/Volumes/MoreStuff/.src/gd2-2.0.12-13/gd-2.0.12/.libs /sw/lib/libiconv.dylib -lXpm -lpng /sw/lib/libjpeg.dylib -lz -ltk -ltcl -lfreetype -lX11 -lpthread -lm > > I would also be interested in knowing the result of pkg-config on > MacOS X. > Of course, the pkg-config package will be needed and PLplot has to be > configured --with-pkg-config. I am interested in the output of the > following command: > > pkg-config --cflags --libs plplotd-c++ ModusOperandi:/sw/fink/dists/local/main/finkinfo koen$ pkg-config --cflags --libs plplotd-c++ -I/sw/include/plplot -L/sw/lib -L/Volumes/MoreStuff/.src/gd2-2.0.12-13/gd-2.0.12/.libs -L/usr/X11R6/lib -lplplotcxxd -lplplotd -liconv -lcsironn -lfreetype -lX11 -ltcl -lcsirocsa -ltk -lz -ljpeg -lgd -lpng -lXpm -lm -lpthread -lqhull - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-17 07:56:26
|
On 2004-01-16 18:44-0500 Koen van der Drift wrote: > > On Jan 16, 2004, at 3:52 AM, Rafael Laboissiere wrote: > > > An easy way to test this is to configure --enable-dyndrivers > > --disable-octave and to see if the problem persists. Anyone, please? > > > They seem to be mutually exclusive. > > Here's the error I get when both are enabled: > > ... > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include > -I/usr/X11R6/include/freetype2 -I../libltdl -I/sw/include -I../libltdl > -Wno-long-double -MT get_drv_info-get-drv-info.o -MD -MP -MF > ".deps/get_drv_info-get-drv-info.Tpo" \ > -c -o get_drv_info-get-drv-info.o `test -f 'get-drv-info.c' || echo > './'`get-drv-info.c; \ > then mv -f ".deps/get_drv_info-get-drv-info.Tpo" > ".deps/get_drv_info-get-drv-info.Po"; \ > else rm -f ".deps/get_drv_info-get-drv-info.Tpo"; exit 1; \ > fi > /bin/sh ../libtool --mode=link gcc -Wno-long-double -L/sw/lib -o > get-drv-info get_drv_info-get-drv-info.o ../libltdl/libltdlc.la > gcc -Wno-long-double -o get-drv-info get_drv_info-get-drv-info.o > -L/sw/lib ../libltdl/.libs/libltdlc.a -ldl > ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc > ltdl.c:2460: failed assertion `dirname' > make[2]: *** [dg300.rc] Error 134 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > ### execution of (export failed, exit code 2 > Failed: compiling plplot-5.2.1.cvs.20040115-11 failed Per seems to see something very similar. This is a wild shot, but here goes: The link step above uses the static library ../libltdl/.libs/libltdlc.a. On Linux for static linking like this, the executable just contains what it needs from the static library so no run-time library path issues are involved. But, Per (or any other Mac OS X expert lurking here), is this the case with MacOS X or do you have to actually specify the directory at run time where the static library resides? Another possibility is perhaps the -ldl library (which libtool does not feel is required in the Linux case) is not being found when get-drv-info is being executed. Per, when you set the environment variable to overcome this problem with executing get-drv-info as part of the build process, what library path(s) do you specify? 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. <ir...@be...> - 2004-01-17 18:13:43
|
On 2004-01-16 23:56-0800 Alan W. Irwin wrote: > Per, when you set the environment variable to overcome this problem with > executing get-drv-info as part of the build process, what library path(s) do you > specify? To expand on this a bit more, the experiments can be quite easy once the build has been completed up to the error. Simply cd drivers and then try the following: ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc with DYLD_LIBRARY_PATH set in various ways to find out the key run-time library directory that should be specified in order to make this command work. Also, if you have the ldd command available to you, you might want to try ldd get-drv-info to see what libraries are required by that 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: Per P. <per...@ma...> - 2004-01-17 20:15:57
|
On Jan 17, 2004, at 19:13, Alan W. Irwin wrote: > On 2004-01-16 23:56-0800 Alan W. Irwin wrote: > >> Per, when you set the environment variable to overcome this problem >> with >> executing get-drv-info as part of the build process, what library >> path(s) do you >> specify? > > To expand on this a bit more, the experiments can be quite easy once > the build > has been completed up to the error. > > Simply > > cd drivers > > and then try the following: > > ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc > > with DYLD_LIBRARY_PATH set in various ways to find out the key > run-time library directory that should be specified in order to make > this > command work. DYLD_LIBRARY_PATH="/Users/per/Documents/Source/sandbox/plplot -5.2.1.cvs.20040115/src/.libs:/Users/per/Documents/Source/sandbox/ plplot-5.2.1.cvs.20040115/lib/csa/.libs" > Also, if you have the ldd command available to you, you > might want to try > > ldd get-drv-info > > to see what libraries are required by that command. Not ldd, but otool... otool -L get-drv-infoget-drv-info: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0) Nothing strange, looks OK to me. However, taking a look at the driver itself: otool -L .libs/dg300.so .libs/dg300.so: /usr/local/lib/libcsirocsa.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/lib/libplplotd.9.dylib (compatibility version 10.0.0, current version 10.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0) Now, there is a fundamental difference between Linux and OS X here: libcsirocsa.0.dylib and libplplotd.9.dylib are shared libs. dg300.so is a "loadable bundle" [19:50:46] per$ export DYLD_LIBRARY_PATH="" [19:50:52] per$ ./get-drv-info dg300 ltdl.c:2460: failed assertion `dirname' When "./get-drv-info dg300" tries to load the bundle dg300 and resolve a symbol, the dynamic loader (dyld) also loads libcsirocsa and libplplotd. They are *not* in the expected places, nor anywhere dyld looks. DYLD_LIBRARY_PATH="path" prepends path to the locations searched by dyld, and problem is solved. /Per |
From: Alan W. I. <ir...@be...> - 2004-01-17 22:45:44
|
On 2004-01-17 21:15+0100 Per Persson wrote: > On Jan 17, 2004, at 19:13, Alan W. Irwin wrote: > > [...] and then try the following: > > > > ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc > > > > with DYLD_LIBRARY_PATH set in various ways to find out the key > > run-time library directory that should be specified in order to make > > this > > command work. > > DYLD_LIBRARY_PATH="/Users/per/Documents/Source/sandbox/plplot > -5.2.1.cvs.20040115/src/.libs:/Users/per/Documents/Source/sandbox/ > plplot-5.2.1.cvs.20040115/lib/csa/.libs" > > > > Also, if you have the ldd command available to you, you > > might want to try > > > > ldd get-drv-info > > > > to see what libraries are required by that command. > > Not ldd, but otool... > > otool -L get-drv-infoget-drv-info: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.0.0) > > Nothing strange, looks OK to me. > However, taking a look at the driver itself: > > otool -L .libs/dg300.so > .libs/dg300.so: > /usr/local/lib/libcsirocsa.0.dylib (compatibility version > 1.0.0, current version 1.0.0) > /usr/local/lib/libplplotd.9.dylib (compatibility version > 10.0.0, current version 10.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.0.0) > > Now, there is a fundamental difference between Linux and OS X here: > libcsirocsa.0.dylib and libplplotd.9.dylib are shared libs. > dg300.so is a "loadable bundle" > > > [19:50:46] per$ export DYLD_LIBRARY_PATH="" > [19:50:52] per$ ./get-drv-info dg300 > ltdl.c:2460: failed assertion `dirname' > > When "./get-drv-info dg300" tries to load the bundle dg300 and resolve > a symbol, the dynamic loader (dyld) also loads libcsirocsa and > libplplotd. They are *not* in the expected places, nor anywhere dyld > looks. > > DYLD_LIBRARY_PATH="path" prepends path to the locations searched by > dyld, and problem is solved. Thanks to Per's above extremely useful information, the trouble with ./get-drv-info has now been clarified to be a run-time library path issue with the dynamically loaded devices. This also fits in with Koen's observation that you get different results with get-drv-info if an old installed version is in place. The autobook (which gives overview documentation of libltdl and lots of other autotools-related stuff) says lt_dlopen (or by inference also its newer lt_dlopenext cousin as used by get-drv-info.c) uses lazy symbol loading when supported by the platform. So on Linux (which has lazy symbol loading) only the one symbol demanded by lt_dlsym in get-drv-info.c is actually loaded and no library symbols are required. This is the only reason that get-drv-info has been working on Linux platforms up to now. My educated guess is the proper thing to do here is set the libtool option -rpath when invoking libtool. So, Per, could you please try the following experiment (lifted from your make output, but with the addition of what I think would be the correct -rpath option): /bin/sh ../libtool --mode=link gcc -g -O2 -o get-drv-info \ get_drv_info-get-drv-info.o ../libltdl/libltdlc.la \ -rpath /Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/src/.libs \ -rpath :/Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/lib/csa/.libs (The libtool documentation says use multiple rpath options rather than a colon separated list). If that command links get-drv-info properly, then please export DYLD_LIBRARY_PATH="" and try that newly linked executable on all the different devices. In particular, does it work for gd or xwin? (Those devices link to additional external libraries besides the internal ones we are dealing with here.) Note that if the above libtool additional -rpath options work for Per's particular situation, then we can straightforwardly configure all the -rpath options for all our internally built libraries, and the result will be that get-drv-info should automatically work on all platforms included those which do not have lazy loading of symbols. 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: Per P. <per...@ma...> - 2004-01-19 01:06:02
|
On Jan 17, 2004, at 23:45, Alan W. Irwin wrote: > My educated guess is the proper thing to do here is set the libtool > option > -rpath when invoking libtool. So, Per, could you please try the > following > experiment (lifted from your make output, but with the addition of > what I > think would be the correct -rpath option): > > /bin/sh ../libtool --mode=link gcc -g -O2 -o get-drv-info \ > get_drv_info-get-drv-info.o ../libltdl/libltdlc.la \ > -rpath > /Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/src/ > .libs \ > -rpath > :/Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/lib/ > csa/.libs FWIW, I don't think the semicolon should be there > > (The libtool documentation says use multiple rpath options rather than > a > colon separated list). > > If that command links get-drv-info properly, then please Yes, it does. > export DYLD_LIBRARY_PATH="" > > and try that newly linked executable on all the different devices. No, doesn't work. Same problem. I had a closer look at what the libtool commands actually expand to: /bin/sh ../libtool --mode=link gcc -g -O2 -o libplplotd.la -rpath /usr/local/lib -version-info 9:0:0 -rpath /usr/local/lib -no-undefined ../lib/csa/libcsirocsa.la -lm pdfutils.lo plargs.lo plbox.lo plcont.lo plcore.lo plctrl.lo plcvt.lo pldtik.lo plfill.lo plfreetype.lo plhist.lo plimage.lo plline.lo plmap.lo plot3d.lo plpage.lo plsdef.lo plshade.lo plstripc.lo plsym.lo pltick.lo plvpor.lo plwind.lo plbuf.lo plgridd.lo ../libltdl/libltdlc.la => gcc -dynamiclib // OK -o .libs/libplplotd.9.0.0.dylib // OK .libs/pdfutils.o // OK, skipping lot of object files -all_load // ??? I think this is bogus, it relates to static libs ../libltdl/.libs/libltdlc.a ../lib/csa/.libs/libcsirocsa.dylib -lm // OK, -lm is not needed, but does no harm either -ldl // <----- WTF! -install_name /usr/local/lib/libplplotd.9.dylib // OK -compatibility_version 10 // OK -current_version 10.0 // OK OK, here's my question: Isn't libtool supposed to use the native linking system? Apple (unfortunately IMHO) have added a 3rd-part compatibility wrapper (libdl) that emulates dlopen() and friends using the native system. Libtool sees dlopen and uses it's semantics rather than dyld's. This is probably a complication. To check it, I moved libdl aside and built plplot. Still didn't work. Anyhow, this is what I'd like to see come out of libtool for the dyndriver modules: [01:46:41] per$ gcc -o .libs/dg300.so -bundle .libs/dg300.o -undefined dynamic_lookup [01:46:57] per$ ./get-drv-info dg300 dg300:DG300 Terminal:0:dg300:25:dg300 (This particular solution only works for OS X >= 10.3) Maybe libtool on OS X just isn't mature enough to handle all the quirks, yet. /Per PS. I'll test the patch from Rafael. (Tomorrow. It's getting late over here...) |
From: Alan W. I. <ir...@be...> - 2004-01-19 02:19:09
|
On 2004-01-19 02:05+0100 Per Persson wrote: > > On Jan 17, 2004, at 23:45, Alan W. Irwin wrote: > > > My educated guess is the proper thing to do here is set the libtool > > option > > -rpath when invoking libtool. So, Per, could you please try the > > following > > experiment (lifted from your make output, but with the addition of > > what I > > think would be the correct -rpath option): > > > > /bin/sh ../libtool --mode=link gcc -g -O2 -o get-drv-info \ > > get_drv_info-get-drv-info.o ../libltdl/libltdlc.la \ > > -rpath > > /Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/src/ > > .libs \ > > -rpath > > :/Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/lib/ > > csa/.libs > > FWIW, I don't think the [...]colon should be there You are correct, that was my cut/paste error. Sorry. > > > > > (The libtool documentation says use multiple rpath options rather than > > a > > colon separated list). > > > > If that command links get-drv-info properly, then please > > Yes, it does. > > > > export DYLD_LIBRARY_PATH="" > > > > and try that newly linked executable on all the different devices. > > No, doesn't work. Same problem. Thanks for that test. ==> The -rpath idea is not going to work. :( Perhaps Rafael's idea will work instead. > -ldl // <----- WTF! > > OK, here's my question: > Isn't libtool supposed to use the native linking system? Apple > (unfortunately IMHO) have added a 3rd-part compatibility wrapper > (libdl) that emulates dlopen() and friends using the native system. > Libtool sees dlopen and uses it's semantics rather than dyld's. This > is probably a complication. I agree, but it is the libtool team's decision to use -ldl for now, and I presume from your previous tests that once built (currently with a DYLD_LIBRARY_PATH workaround which may be superseded by Rafael's fix), the dynamic devices do work. That is you can build and execute some of the examples without problems. > Anyhow, this is what I'd like to see come out of libtool for the > dyndriver modules: > > [01:46:41] per$ gcc -o .libs/dg300.so -bundle .libs/dg300.o > -undefined dynamic_lookup > [01:46:57] per$ ./get-drv-info dg300 > dg300:DG300 Terminal:0:dg300:25:dg300 > > (This particular solution only works for OS X >= 10.3) > > Maybe libtool on OS X just isn't mature enough to handle all the > quirks, yet. You are right. I think the libtool team was caught by surprise that the Mac OS X platform has been so popular. libtool-1.5 was the first libtool version to begin to work at all well with Mac OS X and PLplot even for ordinary linking, and the dynamic driver issues (handled by libtool's libltdl library which is even less mature than libtool itself) is just one more complication. Rafael makes the tarballs with the Debian unstable version of libtool-1.5, and the Debian packager does try to keep up with the latest changes in the libtool-1.5 branch. However, my impression is the libtool team is putting all their energy into the next version (1.6?) rather than doing many changes for libtool-1.5. You might want to try the latest autoconf, automake, and a cvs version of libtool to see if any problems are straightened out, and give feedback to the libtool team accordingly. (Remember, to run ./bootstrap.sh before configure; make; make install if you are using your own autotools versions.) I imagine it will take a while for both OS X and libtool to settle down, and meanwhile we may be stuck with workarounds of one kind or another for PLplot on Mac OS X. Hopefully Koen's efforts at making a fink package for PLplot will hide all these complications from the user. Also, I predict the fink packaging of PLplot will get much easier in the future as both OS X and libtool mature. 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: Per P. <per...@ma...> - 2004-01-20 08:40:02
|
On Jan 19, 2004, at 03:19, Alan W. Irwin wrote: > > Thanks for that test. ==> The -rpath idea is not going to work. :( > > Perhaps Rafael's idea will work instead. > >> -ldl // <----- WTF! > >> >> OK, here's my question: >> Isn't libtool supposed to use the native linking system? Apple >> (unfortunately IMHO) have added a 3rd-part compatibility wrapper >> (libdl) that emulates dlopen() and friends using the native system. >> Libtool sees dlopen and uses it's semantics rather than dyld's. This >> is probably a complication. > > I agree, but it is the libtool team's decision to use -ldl for now, > and I > presume from your previous tests that once built (currently with a > DYLD_LIBRARY_PATH workaround which may be superseded by Rafael's fix), > the > dynamic devices do work. That is you can build and execute some of the > examples without problems. Yes, libdl isn't bad as such. I just meant that it is probably harder to handle edge cases like this with that extra layer of indirection. [snip] > > I imagine it will take a while for both OS X and libtool to settle > down, and > meanwhile we may be stuck with workarounds of one kind or another for > PLplot > on Mac OS X. Hopefully Koen's efforts at making a fink package for > PLplot > will hide all these complications from the user. Also, I predict the > fink > packaging of PLplot will get much easier in the future as both OS X and > libtool mature. Definitely. I'll have to drop this now, for more pressing stuff that keep my family fed.... but, I'll be back! /Per |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-16 11:33:15
|
On Jan 15, 2004, at 9:49 PM, Alan W. Irwin wrote: > > What happens if you start fresh and remove that -lcrt2.o, i.e. > > export FLIBS='-L%p/lib -lfrtbegin -lSystem' > Yes, now it works, and the examples work too. The java and octave examples give some errors though, which I will post later today/tonight. - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-16 16:31:13
|
On 2004-01-16 06:33-0500 Koen van der Drift wrote: > > On Jan 15, 2004, at 9:49 PM, Alan W. Irwin wrote: > > > > > What happens if you start fresh and remove that -lcrt2.o, i.e. > > > > export FLIBS='-L%p/lib -lfrtbegin -lSystem' > > > > Yes, now it works, and the examples work too. Wonderful! That is a huge step in the right direction. > The java and octave > examples give some errors though, which I will post later > today/tonight. I look forward to that additional report. 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-16 23:44:46
|
On Jan 16, 2004, at 11:31 AM, Alan W. Irwin wrote: >> The java and octave >> examples give some errors though, which I will post later >> today/tonight. > > I look forward to that additional report. > I get the errors when I do ./plplot-test.sh: All java examples give the same error: ... Exception in thread "main" java.lang.NoClassDefFoundError: plplot/examples/x01 ... And at the end: ... error: `plplot_octave' undefined near line 4680 column 10 error: evaluating assignment expression near line 4680, column 8 error: called from `plSetOpt' error: evaluating for command near line 4, column 1 error: Permission denied Traceback (most recent call last): File "python/pythondemos.py", line 9, in ? from plplot import * File "/sw/lib/python2.3/site-packages/plplot.py", line 20, in ? from plplotc import * File "/sw/lib/python2.3/site-packages/plplotc.py", line 4, in ? import _plplotc ImportError: No module named _numpy Read 721 data points, 2 separate streams Read 721 data points, 4 separate streams Read 12 data points, 1 separate streams Read 100 data points, 1 separate streams x14 not yet implemented x17 not yet implemented ModusOperandi:~/tmp/plplot5.2.1.cvs.20040115/examples koen$ I do have a package 'numeric-py' installed through fink, maybe 'numpy' is something else? - Koen. |
From: Per P. <per...@ma...> - 2004-01-16 23:51:00
|
On Jan 17, 2004, at 00:44, Koen van der Drift wrote: > error: `plplot_octave' undefined near line 4680 column 10 > Could you please verify that dynamic loading works in octave? There is a simple hello.oct example in the octave sources. There is a bug in octave <2.1.53 (which is not yet released) that breaks .oct files on Mac OS X 10.3.x /Per |
From: Alan W. I. <ir...@be...> - 2004-01-17 02:52:24
|
Executive summary: probable java fix supplied; probable octave fix supplied; need help from Rafael to confirm python2.3 problem; and everything else seemed to work. Details below....Alan On 2004-01-16 18:44-0500 Koen van der Drift wrote: > I get the errors when I do ./plplot-test.sh: > > > All java examples give the same error: > > ... > Exception in thread "main" java.lang.NoClassDefFoundError: > plplot/examples/x01 > ... I expect you didn't have your CLASSPATH defined? Check the documentation in the build tree examples/java/README.javademos (or install tree /yourprefix/lib/java/plplot/examples/README.javademos) for how to set your CLASSPATH. > > And at the end: > > ... > error: `plplot_octave' undefined near line 4680 column 10 > error: evaluating assignment expression near line 4680, column 8 > error: called from `plSetOpt' > error: evaluating for command near line 4, column 1 > error: Permission denied I bet this is our problem. On my system plplot-test.sh has been configured with octavedir line defined as follows: octavedir=/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/share/octave/site/m//:/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/${datadir}/${PACKAGE}${VERSION}/examples/octave//: The tail end of that is symbolic, but I don't see how that can possibly work because non of those symbols are defined by plplot-test.sh or test_octave.sh. Somehow, Linux octave overcomes this problem and still works, but I imagine that is not the case for you. We will fix this in cvs. Meanwhile, as an experiment could you try to work around the problem by editing plplot-test.sh and changing the symbolic values as follows: ${datadir}/${PACKAGE}${VERSION} ==> share/plplot5.2.1.cvs.20040115 That is your result should end up octavedir=/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/share/octave/site/m//:/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/share/plplot5.2.1.cvs.20040115/examples/octave//: (of course with your prefix rather than mine). I have just done that substitution here, and it works fine. > Traceback (most recent call last): > File "python/pythondemos.py", line 9, in ? > from plplot import * > File "/sw/lib/python2.3/site-packages/plplot.py", line 20, in ? > from plplotc import * > File "/sw/lib/python2.3/site-packages/plplotc.py", line 4, in ? > import _plplotc > ImportError: No module named _numpy > > > (out of order) I do have a package 'numeric-py' installed through fink, maybe 'numpy' > is something else? Your configure step almost certainly detected Numeric (which also has the name "numpy"). Otherwise, your python interface would not have been built, the python examples would not have been installed, etc. This one has me puzzled. I am now wondering if the way swig sets up the python interface to PLplot is generally inconsistent with python2.3? I don't have access to python2.3 myself for my Debian stable system. Rafael, can you confirm this problem on your Debian testing or Debian unstable systems? Both should have python2.3 installed. You don't have to run all the demos or even compile anything. Simply cd to the _installed_ examples/python and run pythondemos.py. Make sure first to execute the "python" command from the command-line to be sure you really have the 2.3 version as default (since I believe other versions of python are available as well). > Read 721 data points, 2 separate streams > Read 721 data points, 4 separate streams > Read 12 data points, 1 separate streams > Read 100 data points, 1 separate streams > x14 not yet implemented > x17 not yet implemented The above messages are simply "chatty" ones that indicate all the rest of the examples (for other interfaces than java, octave, and python) built fine. But you should actually look at those postscript file results (*.ps files) with a postscript viewer to make sure you aren't getting garbage results. 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-17 04:05:45
|
On Jan 16, 2004, at 9:52 PM, Alan W. Irwin wrote: > > I expect you didn't have your CLASSPATH defined? No it was not set. However after setting it, I still get the same errors. If I read the docs correctly, it should be set to /prefix/lib/java, correct? I have Java 1.4.1 installed, which is the version that comes with Mac OS X 10.3. > We will fix this in cvs. Meanwhile, as an experiment could you > try to work around the problem by editing plplot-test.sh and changing > the > symbolic values as follows: > > ${datadir}/${PACKAGE}${VERSION} ==> share/plplot5.2.1.cvs.20040115 > No, still the same error :( - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-17 07:19:26
|
On 2004-01-16 23:05-0500 Koen van der Drift wrote: > > On Jan 16, 2004, at 9:52 PM, Alan W. Irwin wrote: > > > > > I expect you didn't have your CLASSPATH defined? > > No it was not set. However after setting it, I still get the same > errors. If I read the docs correctly, it should be set to > /prefix/lib/java, correct? Yes. Could you please let us know the results of the following command: ls /prefix/lib/java/plplot/* Mine gives: ls /usr/local/plplot_at/lib/java/plplot/* /usr/local/plplot_at/lib/java/plplot/core: PLStreamc.class SWIGTYPE_p_p_char.java plplotjavac.java PLStreamc.java config.class plplotjavacJNI.class README.javaAPI config.java plplotjavacJNI.java SWIGTYPE_p_p_char.class plplotjavac.class plplotjavac_wrap.so* /usr/local/plplot_at/lib/java/plplot/examples: README.javademos x04.class x07.java x11.class x14.java x18.class x01.class x04.java x08.class x11.java x15.class x18.java x01.java x05.class x08.java x12.class x15.java x19.class x02.class x05.java x09.class x12.java x16.class x19.java x02.java x06.class x09.java x13.class x16.java x03.class x06.java x10.class x13.java x17.class x03.java x07.class x10.java x14.class x17.java If you don't have those same files could you please send the complete configure, make and make install results as attachments to the list? > > > > We will fix this in cvs. Meanwhile, as an experiment could you > > try to work around the problem by editing plplot-test.sh and changing > > the > > symbolic values as follows: > > > > ${datadir}/${PACKAGE}${VERSION} ==> share/plplot5.2.1.cvs.20040115 > > > > No, still the same error :( Joao, Rafael, I need help here. Should that last part of the octavedir string remain in symbolic form? It does seem to work in Linux, but I cannot understand why. 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-17 14:48:00
|
On Jan 17, 2004, at 2:19 AM, Alan W. Irwin wrote: > Could you please let us know the results of the following command: > > ls /prefix/lib/java/plplot/* > Aha, I see. I copied all java example files to ~/tmp with the other example files. The results of the ls command is now the same on my machine. My mistake, sorry. But if I run ./plplot-test.sh from within ~/tmp/plplot5.2.1.cvs.20040115/examples, I still get the same errors. - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-18 21:18:01
|
* Alan W. Irwin <ir...@be...> [2004-01-17 14:45]: > Thanks to Per's above extremely useful information, the trouble with > ./get-drv-info has now been clarified to be a run-time library path issue > with the dynamically loaded devices. This also fits in with Koen's > observation that you get different results with get-drv-info if an old > installed version is in place. > > The autobook (which gives overview documentation of libltdl and lots of > other autotools-related stuff) says lt_dlopen (or by inference also its > newer lt_dlopenext cousin as used by get-drv-info.c) uses lazy symbol > loading when supported by the platform. So on Linux (which has lazy symbol > loading) only the one symbol demanded by lt_dlsym in get-drv-info.c is > actually loaded and no library symbols are required. This is the only > reason that get-drv-info has been working on Linux platforms up to now. > > My educated guess is the proper thing to do here is set the libtool option > -rpath when invoking libtool. So, Per, could you please try the following > experiment (lifted from your make output, but with the addition of what I > think would be the correct -rpath option): > > /bin/sh ../libtool --mode=link gcc -g -O2 -o get-drv-info \ > get_drv_info-get-drv-info.o ../libltdl/libltdlc.la \ > -rpath /Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/src/.libs \ > -rpath :/Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/lib/csa/.libs I did not fully test your solution, but I explored your good idea and I came up with a solution that will hopefully work everywhere. It is implemented by the following patch to drivers/Makefile.am: =================================================================== --- Makefile.am 17 Jan 2004 16:41:38 -0000 1.36 +++ Makefile.am 18 Jan 2004 20:20:02 -0000 @@ -60,7 +60,14 @@ noinst_PROGRAMS = get-drv-info get_drv_info_SOURCES = get-drv-info.c -get_drv_info_LDADD = $(LIBLTDL) +get_drv_info_LDADD = $(LIBLTDL) \ + $(top_builddir)/src/libplplot${LIB_TAG}.la +if with_csa +get_drv_info_LDADD += $(top_builddir)/lib/csa/libcsirocsa.la +endif +if with_qhull +get_drv_info_LDADD += $(top_builddir)/lib/nn/libcsironn.la +endif get_drv_info_CFLAGS = $(INCLTDL) SUFFIXES = .la .rc =================================================================== By adding *.la entries to get_drv_info_LDADD, when libtool compiles get-drv-info.c it generates now the executable .libs/get-drv-info which contains: $ objdump -x .libs/get-drv-info | fgrep NEEDED NEEDED libplplotd.so.9 NEEDED libfreetype.so.6 NEEDED libz.so.1 NEEDED libcsirocsa.so.0 NEEDED libcsironn.so.0 NEEDED libltdl.so.3 NEEDED libdl.so.2 NEEDED libqhull.so.4 NEEDED libm.so.6 NEEDED libc.so.6 The file ./get-drv-info generated by libtool is now a shell script and it seems to be Linux specific, since it contains references to the libraries in the build tree (*/.libs/lib*.so). My hope is that this will be correctly adjusted on MacOS X. I am going to add this fix to the forthcoming RC1 tarball. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-01-19 00:10:11
|
On 2004-01-18 22:17+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-01-17 14:45]: > > > Thanks to Per's above extremely useful information, the trouble with > > ./get-drv-info has now been clarified to be a run-time library path issue > > with the dynamically loaded devices. This also fits in with Koen's > > observation that you get different results with get-drv-info if an old > > installed version is in place. > > > > The autobook (which gives overview documentation of libltdl and lots of > > other autotools-related stuff) says lt_dlopen (or by inference also its > > newer lt_dlopenext cousin as used by get-drv-info.c) uses lazy symbol > > loading when supported by the platform. So on Linux (which has lazy symbol > > loading) only the one symbol demanded by lt_dlsym in get-drv-info.c is > > actually loaded and no library symbols are required. This is the only > > reason that get-drv-info has been working on Linux platforms up to now. > > > > My educated guess is the proper thing to do here is set the libtool option > > -rpath when invoking libtool. So, Per, could you please try the following > > experiment (lifted from your make output, but with the addition of what I > > think would be the correct -rpath option): > > > > /bin/sh ../libtool --mode=link gcc -g -O2 -o get-drv-info \ > > get_drv_info-get-drv-info.o ../libltdl/libltdlc.la \ > > -rpath /Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/src/.libs \ > > -rpath :/Users/per/Documents/Source/sandbox/plplot-5.2.1.cvs.20040115/lib/csa/.libs > > I did not fully test your solution, but I explored your good idea and I came > up with a solution that will hopefully work everywhere. It is implemented > by the following patch to drivers/Makefile.am: > > =================================================================== > --- Makefile.am 17 Jan 2004 16:41:38 -0000 1.36 > +++ Makefile.am 18 Jan 2004 20:20:02 -0000 > @@ -60,7 +60,14 @@ > > noinst_PROGRAMS = get-drv-info > get_drv_info_SOURCES = get-drv-info.c > -get_drv_info_LDADD = $(LIBLTDL) > +get_drv_info_LDADD = $(LIBLTDL) \ > + $(top_builddir)/src/libplplot${LIB_TAG}.la > +if with_csa > +get_drv_info_LDADD += $(top_builddir)/lib/csa/libcsirocsa.la > +endif > +if with_qhull > +get_drv_info_LDADD += $(top_builddir)/lib/nn/libcsironn.la > +endif > get_drv_info_CFLAGS = $(INCLTDL) > > SUFFIXES = .la .rc > =================================================================== > > By adding *.la entries to get_drv_info_LDADD, when libtool compiles > get-drv-info.c it generates now the executable .libs/get-drv-info which > contains: > > $ objdump -x .libs/get-drv-info | fgrep NEEDED > NEEDED libplplotd.so.9 > NEEDED libfreetype.so.6 > NEEDED libz.so.1 > NEEDED libcsirocsa.so.0 > NEEDED libcsironn.so.0 > NEEDED libltdl.so.3 > NEEDED libdl.so.2 > NEEDED libqhull.so.4 > NEEDED libm.so.6 > NEEDED libc.so.6 > > The file ./get-drv-info generated by libtool is now a shell script and it > seems to be Linux specific, since it contains references to the libraries in > the build tree (*/.libs/lib*.so). My hope is that this will be correctly > adjusted on MacOS X. I think this might work. The current problem on Mac OS X (and all other platforms without lazy symbol resolution) is that all symbols are required to obtain any of them and the needed libraries cannot be found at _run time_ because libtool had no access to where the libraries were located for the get-drv-info link. But now you have explicitly provided the needed information so, as you say, there is hope libtool will do the right thing. However, if this solution does not work, then using the three corresponding -rpath options might do the trick so I am still curious about the results of that -rpath experiment I asked Per to do. 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-14 09:04:01
|
* João Cardoso <jc...@fe...> [2004-01-14 01:32]: > I don't agree, based on what I can see from the reported MacOSX error: > > 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 > > This is the link cmd generated from mkoctfile. You can see no reference to > libcsironn/csa anywhere. However, the linker tries to link with libcsironn/ > csa: > > ld: warning can't open dynamic library: /sw/lib/libcsirocsa.0.dylib > > Where did the loader get that information, else if not from libplplot itself? > Because libplplot was found: -L../../src/.libs -lplplotd Your analysis is apparently correct and I was probably wrong when I stated that the MacOS X linker does not work recursively. However, I still do not understand waht is going on with the MacOS X compilation. In Linux the line above reads: /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd It is much simpler and uses the -shared flag to g++. It seems that the "g++ -bundle" command on MacOS X needs more -L and -l options than the Linux counterpart. > but libcsiroxx wasn't found. MacOSX fellows, if you add > -L../../lib/csa/.libs and -L../../lib/nn/.libs to the above gcc cmd (issued > in the bindings/plplot directory) doesn't the link succeed? In another message, Alan argued that just adding the -L flags may not be enough and we should also add the -l flags. He is probably right. -- Rafael |
From: <jc...@fe...> - 2004-01-14 16:31:05
|
On Wednesday 14 January 2004 09:03, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2004-01-14 01:32]: | > I don't agree, based on what I can see from the reported MacOSX | > error: | > | > 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 | > | > This is the link cmd generated from mkoctfile. You can see no | > reference to libcsironn/csa anywhere. However, the linker tries to | > link with libcsironn/ csa: | > | > ld: warning can't open dynamic library: /sw/lib/libcsirocsa.0.dylib | > | > Where did the loader get that information, else if not from | > libplplot itself? Because libplplot was found: -L../../src/.libs | > -lplplotd | | Your analysis is apparently correct and I was probably wrong when I | stated that the MacOS X linker does not work recursively. | | However, I still do not understand waht is going on with the MacOS X | compilation. In Linux the line above reads: | | /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o | -L../../src/.libs -lplplotd | | It is much simpler and uses the -shared flag to g++. It seems that | the "g++ -bundle" command on MacOS X needs more -L and -l options | than the Linux counterpart. This is because when making libplplot he is told where libcsiroxx are: gcc -shared pdfutils.lo plargs.lo plbox.lo plcont.lo plcore.lo ... -Wl,--rpath -Wl,/home/jcard/plplot/lib/csa/.libs=20 ... ../lib/csa/.libs/libcsirocsa.so=20 | > but libcsiroxx wasn't found. MacOSX fellows, if you add | > -L../../lib/csa/.libs and -L../../lib/nn/.libs to the above gcc cmd | > (issued in the bindings/plplot directory) doesn't the link succeed? | | In another message, Alan argued that just adding the -L flags may not | be enough and we should also add the -l flags. He is probably right. Again I don't agree. The error says clearly that ld is *trying* to link=20 with libsciroxx, but it can't be found; if its location is added to the=20 cmd line, it will be found. But this is mainly academic, now that Alan has decided what THE solution=20 is. Joao |
From: Alan W. I. <ai...@us...> - 2004-01-13 20:30:22
|
On 2004-01-13 18:59+0100 Rafael Laboissiere wrote: > The only thing that is apparently lacking for making the Octave bindings > compile on MacOS are the appropriate library flags. Agreed. Essentially on MacOS X you have to link the octave interface to both libplplot (which is does now), but also _every_ library libplplot links with during its build. (i.e., there is no way to handle hierarchical linking properly with the mkoctfile approach if it is not available natively as in Linux.) But the libraries libplplot links to are going to be difficult to get right as I said in my original post on this thread. It depends on whether you are build tree or install tree, whether you use dynamic drivers or not, etc., etc. libtool handles all this stuff automatically so that is why I am going to try a libtool-based solution. > That said, if Alan finds an elegant and suitable libtool-based solution, why > not? I will try. I believe I have just solved the last fundamental problem. I can now generate OCTAVEINCCMD, and OCTAVELIBCMD using mkoctfile. I haven't tried those yet with libtool, but I see no reason for it not to work. Anyhow, if the approach works for my Debian stable system, I will commit it (hopefully in the next hour or so) and see what you think. As far as I am concerned, I just want to see the problem solved so if it is necessary to revert my commits because you or Joao have come up with a more elegant solution to replace it or because my solution just doesn't work cross-platform that is fine. 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-13 22:03:38
|
* Alan W. Irwin <ai...@us...> [2004-01-13 12:29]: > I believe I have just solved the last fundamental problem. I can now > generate OCTAVEINCCMD, and OCTAVELIBCMD using mkoctfile. I haven't tried > those yet with libtool, but I see no reason for it not to work. Anyhow, if > the approach works for my Debian stable system, I will commit it (hopefully > in the next hour or so) and see what you think. Remember that the mkoctfile script does much more than merely providing include and lib flags for compilation/link. In fact, it can recognize arguments, can issue compile and link commands, and finish the *.oct files up, all that respecting the various settings that were done during the configuration of Octave in the target system. I hope that your solution will not hijack the mkoctfile command line for building the *.oct file. I would much prefer to take a similar approach as I did for the generation of the pkg-config files, namely by parsing the .libs/libplplotd.la file and extracting the link information needed to mkoctfile. It would be equivalent to what Joao proposed (using pkg-config as an example): mkoctfile <args> `pkg-config --libs plplotd` with `pkg-config --libs plplotd` being replaced by the result of the parsing of the .la file. At any event, I am afraid that this change will make HEAD too unstable and this will push our release schedule back. What about making this changes post-release? We could do a 5.3.1 bug-fixing release next month. -- Rafael |
From: Alan W. I. <ai...@us...> - 2004-01-14 02:30:34
|
On 2004-01-13 12:29-0800 Alan W. Irwin wrote: > I believe I have just solved the last fundamental problem. I can now > generate OCTAVEINCCMD, and OCTAVELIBCMD using mkoctfile. I haven't tried > those yet with libtool, but I see no reason for it not to work. Anyhow, if > the approach works for my Debian stable system, I will commit it (hopefully > in the next hour or so) and see what you think. hmm. That hour or so became somewhat expanded because I was having trouble with both libtool and automake in dealing with the strange octave naming conventions for its interface shared objects. But the new libtool method now works for me (at least in the install directory). N.B. There is a g++ header file name clash with our own directory tree. The compile command includes the normal -I../.., but one of the includes buried deep in the include structure does #include <new> (or something like that) which finds our ../../new directory and crashes. Getting rid of -I../.. solved the problem, but I don't know how to do that in libtool. The workaround I finally used was to mv the PLplot new directory (which currently is filled with nothing important) somewhere else. If you have a similar problem do the same for now. We can think of a permanent solution later (such as removing new from cvs or renaming it) if you like this libtool approach. I think we will want a permanent solution in any case because our "new" directory tree name is just an accident waiting to happen because of that -I../.. The Makefile.am changes should be considered a first cut, and I am sure there are much more elegant libtool methods for doing the same job. I don't know how to use octave in the build tree so that is untested (although I tried to support it). I did test octave examples in the install tree, and they worked fine. There are still some cross-platform issues. For example, the mv and copy commands which are used to create the install tree plplot_octave.oct and build tree plplot_octave.oct assume the original file has a suffix of .so which won't work on all unix platforms. (I tried to change that with -shrext, but I couldn't get it to work.) There are ways around this (such as grepping in the *.la file), but I would prefer to find out how to make -shrext work. Please test this on your Linux systems for now and see how you like it. 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 __________________________ |