From: Alan W. I. <ir...@be...> - 2003-03-25 06:07:45
|
Here is the current status of plplot on netbsd. There is one issue that is a real showstopper for netbsd (and perhaps other unices). The ./get-drv-info helper application segfaults when it tries to obtain information about the xwin driver. This is a really quite simple routine that works for all other drivers (although I don't have a chance to try it on tk because of the issue below). There is nothing obviously wrong with the xwin.so linking. When I look for undefined symbols using nm -u, I can spot obvious libX11, libm, and libplplot symbols, plus a very few I don't recognize. However, those libraries are all linked in, and there are no obvious error or warning messages associated with the linking process (which I believe there would be if another library needed to be specified by the link to resolve some undefined symbols). That leaves the most obvious candidate for the ./get-drv-info segfault as the libltdl library that is used by ./get-drv-info and which comes with my libtool version (libtool-1.4.3 straight from FSF). Besides the segfault there are also a number of valgrind "Conditional jump or move depends on uninitialised value(s)" associated with running ./get-drv-info on Linux. These message at best indicate the FSF guys haven't tried valgrind on their libltdl library and at worst may indicate a real memory management problem with that library. Rafael, we should do a test also with your libtool (patched Debian libtool-1.4.3) as soon as you finish the perl stuff and can make a tarball. Also, if that doesn't work, we should discuss the possibility of trying later libtool versions. Here are some additional issues that need to be addressed but which I can bypass for now using --disable-tcl --without-freetype --disable-octave * tcl/tk does not work because of the tcl/tk configuration design problems I described here previously (and which I hope Maurice can help to sort out). * freetype does not work because ft2build.h (which is #included by our plfreetype software) apparently is not part of the netbsd distribution of freetype2 (version 2.1.3 which is certainly pretty up-to-date). I suspect this is a deprecated file in any case since all it seems to do is #include <freetype/config/ftheader.h>. Andrew, do you forsee any problem if we replace #include <ft2build.h> by #include <freetype/config/ftheader.h> in plfreetype.h? * octave doesn't work because perl scripts refer to the wrong perl path #!/usr/bin/perl (rather than /usr/pkg/bin/perl) on netbsd. One possibility is to change all our perl scripts so they all start with #!/usr/bin/env perl, but Rafael has decided a better way (and I agree) is simply to invoke perl explicitly by using $(PERL) scriptname_whatever throughout our Makefile.am files. So the netbsd score is 3 avoided problems (all of which could be sorted out quickly) and one showstopper. If there is some adventurous soul here, who would like to help out with the showstopper problem, it would be most interesting to see whether there are segfaults with get-drv-info on any other Linux or Unix platform. Joao, you have voiced a few concerns for OSF1, but they don't seem to involve get-drv-info. Can you please confirm that helper application is working well (especially for xwin and tk) for OSF1 as well as SuSe? BTW, the test week for our users is currently scheduled starting 12th April with the actual release scheduled on the 19th so I think it is time in any case for other developers besides Joao and me to start doing some testing of the CVS snapshot tarballs on all platforms they have access to. Ideally, we would have all known portability issues solved on the platforms accessible to us as a group before our users put the release candidate tarball through its paces during test week. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-25 13:54:45
|
* Alan W. Irwin <ir...@be...> [2003-03-24 22:05]: > That leaves the most obvious candidate for the ./get-drv-info segfault as > the libltdl library that is used by ./get-drv-info and which comes with my > libtool version (libtool-1.4.3 straight from FSF). Besides the segfault > there are also a number of valgrind "Conditional jump or move depends on > uninitialised value(s)" associated with running ./get-drv-info on Linux. > These message at best indicate the FSF guys haven't tried valgrind on their > libltdl library and at worst may indicate a real memory management problem > with that library. Rafael, we should do a test also with your libtool > (patched Debian libtool-1.4.3) as soon as you finish the perl stuff and can > make a tarball. Also, if that doesn't work, we should discuss the > possibility of trying later libtool versions. > > [...] > > * octave doesn't work because perl scripts refer to the wrong perl path > #!/usr/bin/perl (rather than /usr/pkg/bin/perl) on netbsd. One possibility > is to change all our perl scripts so they all start with #!/usr/bin/env > perl, but Rafael has decided a better way (and I agree) is simply to invoke > perl explicitly by using $(PERL) scriptname_whatever throughout our > Makefile.am files. A new release-candidate tarball is availabale at the usual place (http://people.debian.org/~rafael/plplot.html) which should fix the problems above. Let us hope that the libltdl library included by my Debian system will do better than that of FSF, present in Alan's machine. > BTW, the test week for our users is currently scheduled starting 12th April > with the actual release scheduled on the 19th [...] It is probably a better idea to announce widely and immediately the availability of the release candidate tarballs, even if not all the portability problems are fixed. The sooner the users start trying it, the sooner they will found bugs that we have overseen and the higher are the chances that we keep our schedule in time. Why wait until April 12th? -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-25 17:02:00
|
On Tue, 25 Mar 2003, Rafael Laboissiere wrote: > It is probably a better idea to announce widely and immediately the > availability of the release candidate tarballs, even if not all the > portability problems are fixed. The sooner the users start trying it, the > sooner they will found bugs that we have overseen and the higher are the > chances that we keep our schedule in time. Why wait until April 12th? > We have actually already advertised the CVS snapshots (not "release candidate", please, see below) on plplot-general. I encourage you to make another announcement there strongly asking for testing help. We have had nearly 4000 downloads of the 5.2.0 tarball as a result of my last release announcement on that list so that is a pretty good announcement venue. Also, I assume you are getting widespread Debian testing exposure through your package releases there. BTW, I like the cautious phrasing you use in announcing the Debian packages. IMHO that caution is still appropriate because we are far from a release candidate at the moment. I would prefer our team of Unix cross-platform testers (Joao, Maurice, and me and anybody else lurking on this list) to finish our tests on the various platforms accessible to us before we start advertising a release candidate. What's the consensus here on that issue and much more importantly do the cross-platform testers think you can finish your testing by 12 April? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-25 17:18:14
|
* Alan W. Irwin <ir...@be...> [2003-03-25 09:00]: > We have actually already advertised the CVS snapshots (not "release > candidate", please, see below) on plplot-general. I encourage you to make > another announcement there strongly asking for testing help. We have had > nearly 4000 downloads of the 5.2.0 tarball as a result of my last release > announcement on that list so that is a pretty good announcement venue. Also, > I assume you are getting widespread Debian testing exposure through your > package releases there. > > BTW, I like the cautious phrasing you use in announcing the Debian packages. > IMHO that caution is still appropriate because we are far from a release > candidate at the moment. I would prefer our team of Unix cross-platform > testers (Joao, Maurice, and me and anybody else lurking on this list) to > finish our tests on the various platforms accessible to us before we start > advertising a release candidate. I think that advertising the tarballs now as release candidates will have the psychological advantage of making users conscious of the proximity of the release. Hence, they will be more willing to download the beast and test it. "CVS snapshot" is not as sexy and exciting as "Release Candidate". I cannot (of course) prove my claim and, since you are the Release Engineer, the final word is yours. I am just afraid that only one week for users tests will be too short. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-25 18:03:03
|
On Tue, 25 Mar 2003, Rafael Laboissiere wrote: > I think that advertising the tarballs now as release candidates will have > the psychological advantage of making users conscious of the proximity of > the release. Hence, they will be more willing to download the beast and > test it. "CVS snapshot" is not as sexy and exciting as "Release Candidate". > > I cannot (of course) prove my claim and, since you are the Release Engineer, > the final word is yours. I am just afraid that only one week for users > tests will be too short. Actually, I agree with your claim that calling it a release candidate will encourage people to try it more at this early date. But my opinion is "release candidate" is a special phrase that implies thorough testing by us, and I don't want the user's to get that wrong impression and then angrily flood us with a bunch of similar bug reports about something we should have caught with our own testing. I went through that poorly tested scenario with PLplot-5.2.0, and I don't wish to repeat it if "release candidate" unfairly raises the expectations of our users. But that is the essential question here. Does "release candidate" no longer have any special meaning to our users since the phrase has been mis-used so often for other projects? What do the rest of you think? If there is strong support amongst the developers here to call what we currently have (segfaults and all) a release candidate, I would be willing to go along. Or maybe there is some compromise wording such as "pre-release candidate" we would all be happy with? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2003-03-26 01:05:29
|
Here is an update on the netbsd status. On Mon, 24 Mar 2003, Alan W. Irwin wrote: > Here is the current status of plplot on netbsd. > > There is one issue that is a real showstopper for netbsd (and perhaps other > unices). The ./get-drv-info helper application segfaults when it tries to > obtain information about the xwin driver. This is still a showstopper with Rafael's patched debian version of libtool. ./get-drv-info xwin Segmentation fault (core dumped) ./get-drv-info gd jpeg:JPEG file:0:gd:40:jpeg png:PNG file:0:gd:39:png Rafael, can you recommend some later version of libtool for me to try? Are they close to their next release now? Joao, do you have any OSF1 results for using the ./get-drv-info xwin command in the drivers directory? > > Here are some additional issues that need to be addressed but which I can > bypass for now using --disable-tcl --without-freetype --disable-octave The tcl issue is still not addressed. I had some correspondence with Andrew about the freetype issue. Apparently, ft2build.h is considered an essential front end to more volatile changes in other freetype2 headers so it should not be bypassed. Since netbsd did not include ft2build.h, our conclusion is freetype2 packaging is broken for netbsd. For all further netbsd tests I will turn off freetype using --without-freetype. Rafael's perl changes allowed me to try octave on netbsd, but I conclude mkoctfile or the octave installation is broken there. The compile step is done with the same warning messages as on the Linux side of things, but the link step is done with a bare ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd command which generates the following messages: ld: warning: cannot find entry symbol _start; defaulting to 00014d98 plplot_octave.o: In function `str_vec_compare(void const *, void const *)': plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::compare(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &, unsigned long, unsigned long) const' plplot_octave.o: In function `_arraylen(octave_value const &)': plplot_octave.o(.text+0x1b00): undefined reference to `umul' plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to `octave_value::octave_value(void)' plus hundreds more of these undefined references. The equivalent command on the Linux side is fairly similar: /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd but of course with no warnings or messages. mkoctfile is supposed to have some sort of cross-platform support, but as far as I can tell when comparing the Linux and netbsd versions there is little difference between them except the link command differences above. It may be that in order to overcome this problem, we would have to go to a more powerful cross-platform solution such as libtool. Rafael and Joao have not been keen on replacing mkoctfile with libtool to build the octave interface to plplot, but if they change their minds (after the current release; it is too late in this release cycle to try it), netbsd is a good test platform for a libtool solution. For example, I am glad I moved from the python native solution we had before (setup.py) to libtool to build the python interface to plplot. That seems to work fine for netbsd (and every other platform where we have tried it) while the native method had lots of ifs, ands, and buts from one platform to the next. For now, I will avoid octave on netbsd by --disable-octave. So the scorecard is two issues (freetype and octave) which we have resolved by disabling since something is broken on netbsd, tcl/tk (still to be resolved), and the segfault which continues to be a major worry. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-03-26 02:00:22
|
On Wednesday 26 March 2003 01:02, Alan W. Irwin wrote: > Here is an update on the netbsd status. > > On Mon, 24 Mar 2003, Alan W. Irwin wrote: > > Here is the current status of plplot on netbsd. > > > > There is one issue that is a real showstopper for netbsd (and perhaps > > other unices). The ./get-drv-info helper application segfaults when it > > tries to obtain information about the xwin driver. > > This is still a showstopper with Rafael's patched debian version of > libtool. > > ./get-drv-info xwin > Segmentation fault (core dumped) > > ./get-drv-info gd > jpeg:JPEG file:0:gd:40:jpeg > png:PNG file:0:gd:39:png > > Rafael, can you recommend some later version of libtool for me > to try? Are they close to their next release now? > > Joao, do you have > any OSF1 results for using the > > ./get-drv-info xwin > > command in the drivers directory? Yes, it is OK: bash-2.01$ ./get-drv-info gd Could not open driver module gd bash-2.01$ ./get-drv-info ps ps:PostScript File (monochrome):0:ps:29:psm psc:PostScript File (color):0:ps:30:pscbash-2.01$ bash-2.01$ ./get-drv-info xwin xwin:X-Window (Xlib):1:xwin:5:xwbash-2.01$ I still had not time to test the isnan configure issue. Joao > > > Here are some additional issues that need to be addressed but which I can > > bypass for now using --disable-tcl --without-freetype --disable-octave > > The tcl issue is still not addressed. > > I had some correspondence with Andrew about the freetype issue. > Apparently, ft2build.h is considered an essential front end to more > volatile changes in other freetype2 headers so it should not be bypassed. > Since netbsd did not include ft2build.h, our conclusion is freetype2 > packaging is broken for netbsd. For all further netbsd tests I will turn > off freetype using --without-freetype. > > Rafael's perl changes allowed me to try octave on netbsd, but I conclude > mkoctfile or the octave installation is broken there. The compile step is > done with the same warning messages as on the Linux side of things, but the > link step is done with a bare > > ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd > > command which generates the following messages: > > ld: warning: cannot find entry symbol _start; defaulting to 00014d98 > plplot_octave.o: In function `str_vec_compare(void const *, void const *)': > plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char, > string_char_traits<char>, __default_alloc_template<false, 0> > >::compare(basic_string<char, string_char_traits<char>, > __default_alloc_template<false, 0> > const &, unsigned long, unsigned long) > const' plplot_octave.o: In function `_arraylen(octave_value const &)': > plplot_octave.o(.text+0x1b00): undefined reference to `umul' > plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list > const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to > `octave_value::octave_value(void)' This looks like a libstdc question? Or a static Octave? Is Octave compiled with shared libs? What do ldd `which octave` reports? Does liboctinterp/liboctave/libcruft appears? ... liboctinterp.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctinterp.so.2.1.36 liboctave.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctave.so.2.1.36 libcruft.so.2.1.36 => /usr/local/lib/octave-2.1.36/libcruft.so.2.1.36 ... > > plus hundreds more of these undefined references. > > The equivalent command on the Linux side is fairly similar: > > /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs > -lplplotd > > but of course with no warnings or messages. > > mkoctfile is supposed to have some sort of cross-platform support, but as > far as I can tell when comparing the Linux and netbsd versions there is > little difference between them except the link command differences above. > > It may be that in order to overcome this problem, we would have to go to a > more powerful cross-platform solution such as libtool. Rafael and Joao > have not been keen on replacing mkoctfile with libtool to build the octave > interface to plplot, but if they change their minds (after the current > release; it is too late in this release cycle to try it), netbsd is a good > test platform for a libtool solution. For example, I am glad I moved from > the python native solution we had before (setup.py) to libtool to build the > python interface to plplot. That seems to work fine for netbsd (and every > other platform where we have tried it) while the native method had lots of > ifs, ands, and buts from one platform to the next. > > For now, I will avoid octave on netbsd by --disable-octave. > > So the scorecard is two issues (freetype and octave) which we have resolved > by disabling since something is broken on netbsd, tcl/tk (still > to be resolved), and the segfault which continues to be a major worry. > > 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 Canadian Centre for Climate Modelling and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2003-03-26 03:06:27
|
On Wed, 26 Mar 2003, Joao Cardoso wrote: > > Joao, do you have > > any OSF1 results for using the > > > > ./get-drv-info xwin > > > > command in the drivers directory? > > Yes, it is OK: > > bash-2.01$ ./get-drv-info gd > Could not open driver module gd > bash-2.01$ ./get-drv-info ps > ps:PostScript File (monochrome):0:ps:29:psm > psc:PostScript File (color):0:ps:30:pscbash-2.01$ > bash-2.01$ ./get-drv-info xwin > xwin:X-Window (Xlib):1:xwin:5:xwbash-2.01$ Thanks for that additional information. > > command which generates the following messages: > > > > ld: warning: cannot find entry symbol _start; defaulting to 00014d98 > > plplot_octave.o: In function `str_vec_compare(void const *, void const *)': > > plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char, > > string_char_traits<char>, __default_alloc_template<false, 0> > > >::compare(basic_string<char, string_char_traits<char>, > > __default_alloc_template<false, 0> > const &, unsigned long, unsigned long) > > const' plplot_octave.o: In function `_arraylen(octave_value const &)': > > plplot_octave.o(.text+0x1b00): undefined reference to `umul' > > plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list > > const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to > > `octave_value::octave_value(void)' > > This looks like a libstdc question? Or a static Octave? Is Octave compiled > with shared libs? What do > > ldd `which octave` > > reports? Does liboctinterp/liboctave/libcruft appears? > > ... > liboctinterp.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctinterp.so.2.1.36 > liboctave.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctave.so.2.1.36 > libcruft.so.2.1.36 => /usr/local/lib/octave-2.1.36/libcruft.so.2.1.36 ldd `which octave` /usr/pkg/bin/octave: -loctinterp.2 => /usr/pkg/lib/liboctinterp.so.2 -loctave.2 => /usr/pkg/lib/liboctave.so.2 -lcruft.2 => /usr/pkg/lib/libcruft.so.2 -lreadline.4 => /usr/pkg/lib/libreadline.so.4 -lcurses.5 => /usr/lib/libcurses.so.5 -lz.0 => /usr/lib/libz.so.0 -lg2c.1 => /usr/lib/libg2c.so.1 -lstdc++.4 => /usr/lib/libstdc++.so.4 -lm.0 => /usr/lib/libm.so.0 -lc.12 => /usr/lib/libc.so.12 Thanks for that suggestion (which I should have thought of myself). It appears that octave is dynamically linked to all these libraries (including libcruft) and they are all present on the netbsd system. Inspired by your question and these results, I did a lot of experimentation and finally found that if ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd is replaced by g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd then all the linking problems disappear! So clearly, the netbsd version of mkoctfile is set up improperly for that system: i.e., grep SH_LD `which mkoctfile` |grep '=' : ${SH_LD="ld"} : ${SH_LDFLAGS=""} When it should have been the Linux result: grep SH_LD `which mkoctfile` | grep '=' : ${SH_LD="/usr/bin/g++"} : ${SH_LDFLAGS="-shared"} Have you been able to build octave on your OSF1 system? I am trying to get some idea (2 data points are more statistically significant than 1 ...;-)) whether this is just a netbsd problem with mkoctfile or are we going to have consistent problems when we use mkoctfile on any Unix system other than Linux? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-26 07:28:54
|
* Alan W. Irwin <ir...@be...> [2003-03-25 19:05]: > Inspired by your question and these results, I did a lot of experimentation > and finally found that if > > ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd > > is replaced by > > g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd > > then all the linking problems disappear! So clearly, the netbsd version of > mkoctfile is set up improperly for that system: > > i.e., > > grep SH_LD `which mkoctfile` |grep '=' > : ${SH_LD="ld"} > : ${SH_LDFLAGS=""} > > > When it should have been the Linux result: > > grep SH_LD `which mkoctfile` | grep '=' > : ${SH_LD="/usr/bin/g++"} > : ${SH_LDFLAGS="-shared"} We could find a workaround for this brokenness by checking for g++ in configure.ac and modifying bindings/octave/Makefile.am such that mkoctfile is invoked like this for netbsd: SH_LD="/usr/bin/g++" SH_LDFLAGS="-shared" mkoctfile [...] Please, could you confirm that the above work in your netbsd system? An aside question: what is the result of this in netbsd: echo `uname -s`-`uname -r` ? -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-26 14:56:10
|
On Wed, 26 Mar 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-03-25 19:05]: > > grep SH_LD `which mkoctfile` |grep '=' > > : ${SH_LD="ld"} > > : ${SH_LDFLAGS=""} > > > > > > When it should have been the Linux result: > > > > grep SH_LD `which mkoctfile` | grep '=' > > : ${SH_LD="/usr/bin/g++"} > > : ${SH_LDFLAGS="-shared"} > > We could find a workaround for this brokenness by checking for g++ in > configure.ac and modifying bindings/octave/Makefile.am such that mkoctfile > is invoked like this for netbsd: > > SH_LD="/usr/bin/g++" SH_LDFLAGS="-shared" mkoctfile [...] > > Please, could you confirm that the above work in your netbsd system? Yes, that works. But I hate like hell to embed special stuff in our own configuration system just to compensate for this brokeness. If you do something like that please put lots of warning commentary around it that it stays in our configuration only as long as netbsd is broken. > > An aside question: what is the result of this in netbsd: > > echo `uname -s`-`uname -r` NetBSD-1.6M 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-26 14:59:08
|
* Alan W. Irwin <ir...@be...> [2003-03-26 06:54]: > Yes, that works. But I hate like hell to embed special stuff in our own > configuration system just to compensate for this brokeness. If you do > something like that please put lots of warning commentary around it that it > stays in our configuration only as long as netbsd is broken. Okay. -- Rafael |
From: <jc...@fe...> - 2003-03-26 10:01:25
|
On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote: | On Wed, 26 Mar 2003, Joao Cardoso wrote: ... | Inspired by your question and these results, I did a lot of | experimentation and finally found that if | | ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd | | is replaced by | | g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs | -lplplotd | | then all the linking problems disappear! So clearly, the netbsd | version of mkoctfile is set up improperly for that system: Could you please run from within octave the command octave_config_info and tell us the result? Thanks, Joao |
From: Alan W. I. <ir...@be...> - 2003-03-26 15:25:53
|
On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > Could you please run from within octave the command > > octave_config_info > > and tell us the result? Although you told me later you didn't need this information, I thought the question might come up again so I decided to give this information anyhow. Please save for future reference. octave GNU Octave, version 2.1.34 (sparc--netbsdelf). Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 John W. Eaton. This is free software with ABSOLUTELY NO WARRANTY. For details, type warranty'. *** This is a development version of Octave. Development releases *** are provided for people who want to help test, debug, and improve *** Octave. *** *** If you want a stable, well-tested version of Octave, you should be *** using one of the stable releases (when this development release *** was made, the latest stable version was 2.0.16). octave:1> octave_config_info ans =3D { ALL_CFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../= glob -I =2E./glob -I/usr/pkg/include -DHAVE_CONFIG_H -O2 ALL_CXXFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I.= =2E/glob -I../glob -I/usr/pkg/include -DHAVE_CONFIG_H -fno-implicit-templates -O2 ARFLAGS =3D rc CFLAGS =3D -O2 CPPFLAGS =3D CXXFLAGS =3D -O2 CXX_VERSION =3D 2.95.3 20010315 (release) (NetBSD nb3) F2CFLAGS =3D FLIBS =3D LD_STATIC_FLAG =3D LEXLIB =3D LIBEXT =3D la LIBKPATHSEA =3D ../kpathsea/libkpathsea.a RANLIB =3D ranlib RDYNAMIC_FLAG =3D -rdynamic SHARED_LIBS =3D true SHLEXT =3D so YACC =3D ../missing bison bindir =3D /usr/pkg/bin imagepath =3D .:/usr/pkg/share/octave/2.1.34/imagelib// localoctfiledir =3D /usr/pkg/libexec/octave/site/oct/sparc--netbsdelf CPICFLAG =3D -fPIC CXXPICFLAG =3D -fPIC FC =3D cc FORTRAN_MAIN_FLAG =3D -u MAIN__ LEX =3D flex LFLAGS =3D -t -I LIBOCTAVE =3D -loctave STATIC_LIBS =3D true datadir =3D /usr/pkg/share localfcnfiledir =3D /usr/pkg/share/octave/site/m octincludedir =3D /usr/pkg/include/octave-2.1.34 EXE =3D GLOB_INCFLAGS =3D -I../glob -I../glob -I/usr/pkg/include LIBPLPLOT =3D LIBS =3D -lz -lm SH_LD =3D ld TERMLIBS =3D -lcurses UGLY_DEFS =3D -DOCTAVE_SOURCE=3D1 -DSEPCHAR=3D':' -DSEPCHAR_STR=3D":" -DU= SE_READLINE=3D1 -D__NO_MATH_INLINES=3D1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=3D1 -DHAVE_LIBM=3D1= -DHAVE_LIB Z=3D1 -DF77_APPEND_UNDERSCORE=3D1 -DHAVE_GETHOSTNAME=3D1 -DHAVE_GETPWNAM=3D= 1 -DSIZEOF_SH ORT=3D2 -DSIZEOF_INT=3D4 -DSIZEOF_LONG=3D4 -DSIZEOF_LONG_LONG=3D8 -DHAVE_AL= LOCA=3D1 -DNPOS =3Dstd::string::npos -DSTDC_HEADERS=3D1 -DHAVE_DIRENT_H=3D1 -DTIME_WITH_SYS= _TIME=3D1 -DH AVE_SYS_WAIT_H=3D1 -DHAVE_ASSERT_H=3D1 -DHAVE_CURSES_H=3D1 -DHAVE_DLFCN_H= =3D1 -DHAVE_FCN TL_H=3D1 -DHAVE_FLOAT_H=3D1 -DHAVE_FNMATCH_H=3D1 -DHAVE_GLOB_H=3D1 -DHAVE_G= RP_H=3D1 -DHAVE _IEEEFP_H=3D1 -DHAVE_LIMITS_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_POLL_H=3D1 -DH= AVE_PWD_H=3D1 - DHAVE_SGTTY_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1 -DHAVE_SYS_IOCTL_= H=3D1 -DHAVE_ SYS_PARAM_H=3D1 -DHAVE_SYS_POLL_H=3D1 -DHAVE_SYS_RESOURCE_H=3D1 -DHAVE_SYS_= SELECT_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_SYS_TIME_H=3D1 -DHAVE_SYS_TIMES_H=3D1 -DHAVE_S= YS_TYPES_H=3D 1 -DHAVE_SYS_UTSNAME_H=3D1 -DHAVE_TERMCAP_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_= VARARGS_H=3D1 -DHAVE_ATEXIT=3D1 -DHAVE_BCOPY=3D1 -DHAVE_BZERO=3D1 -DHAVE_DUP2=3D1 -DHAVE= _ENDGRENT=3D1 - DHAVE_ENDPWENT=3D1 -DHAVE_EXECVP=3D1 -DHAVE_FCNTL=3D1 -DHAVE_FORK=3D1 -DHAV= E_GETCWD=3D1 -D HAVE_GETEGID=3D1 -DHAVE_GETEUID=3D1 -DHAVE_GETGID=3D1 -DHAVE_GETGRENT=3D1 -= DHAVE_GETGRGI D=3D1 -DHAVE_GETGRNAM=3D1 -DHAVE_GETPGRP=3D1 -DHAVE_GETPID=3D1 -DHAVE_GETPP= ID=3D1 -DHAVE_G ETPWENT=3D1 -DHAVE_GETPWUID=3D1 -DHAVE_GETTIMEOFDAY=3D1 -DHAVE_GETUID=3D1 -= DHAVE_GETWD=3D1 -DHAVE_LINK=3D1 -DHAVE_LOCALTIME_R=3D1 -DHAVE_LSTAT=3D1 -DHAVE_MEMMOVE=3D1= -DHAVE_MKDIR =3D1 -DHAVE_MKFIFO=3D1 -DHAVE_PIPE=3D1 -DHAVE_POLL=3D1 -DHAVE_PUTENV=3D1 -D= HAVE_READLINK=3D1 -DHAVE_RENAME=3D1 -DHAVE_RINDEX=3D1 -DHAVE_RMDIR=3D1 -DHAVE_SELECT=3D1 -DH= AVE_SETGRENT=3D 1 -DHAVE_SETPWENT=3D1 -DHAVE_SETVBUF=3D1 -DHAVE_SIGACTION=3D1 -DHAVE_SIGPEN= DING=3D1 -DHA VE_SIGPROCMASK=3D1 -DHAVE_SIGSUSPEND=3D1 -DHAVE_STAT=3D1 -DHAVE_STRCASECMP= =3D1 -DHAVE_ST RDUP=3D1 -DHAVE_STRERROR=3D1 -DHAVE_STRFTIME=3D1 -DHAVE_STRNCASECMP=3D1 -DH= AVE_STRPTIME=3D 1 -DHAVE_SYMLINK=3D1 -DHAVE_TEMPNAM=3D1 -DHAVE_UMASK=3D1 -DHAVE_UNLINK=3D1 = -DHAVE_USLEEP =3D1 -DHAVE_VFPRINTF=3D1 -DHAVE_VSPRINTF=3D1 -DHAVE_VSNPRINTF=3D1 -DHAVE_WA= ITPID=3D1 -DSMA RT_PUTENV=3D1 -DHAVE_DLOPEN=3D1 -DHAVE_DLSYM=3D1 -DHAVE_DLERROR=3D1 -DHAVE_= DLCLOSE=3D1 -DW ITH_DL=3D1 -DWITH_DYNAMIC_LINKING=3D1 -DHAVE_TIMEVAL=3D1 -DHAVE_FINITE=3D1 = -DHAVE_ISNAN=3D 1 -DHAVE_ISINF=3D1 -DHAVE_ACOSH=3D1 -DHAVE_ASINH=3D1 -DHAVE_ATANH=3D1 -DHAV= E_ERF=3D1 -DHAV E_ERFC=3D1 -DHAVE_ST_BLKSIZE=3D1 -DHAVE_ST_BLOCKS=3D1 -DHAVE_ST_RDEV=3D1 -D= HAVE_TM_ZONE=3D 1 -DHAVE_GR_PASSWD=3D1 -DEXCEPTION_IN_MATH=3D1 -DRETSIGTYPE=3Dvoid -DSYS_SI= GLIST_DECLA RED=3D1 -DHAVE_SYS_SIGLIST=3D1 -DHAVE_POSIX_SIGNALS=3D1 -DHAVE_GETRUSAGE=3D= 1 -DHAVE_TIME S=3D1 -DGNUPLOT_HAS_MULTIPLOT=3D1 -DGNUPLOT_HAS_FRAMES=3D1 WITH_SHL =3D false exec_prefix =3D /usr/pkg imagedir =3D /usr/pkg/share/octave/2.1.34/imagelib startupfiledir =3D /usr/pkg/share/octave/2.1.34/m/startup ALL_FFLAGS =3D -O AR =3D ar BLAS_LIBS =3D CC_VERSION =3D 2.95.3 20010315 (release) (NetBSD nb3) CXX =3D c++ DEFAULT_PAGER =3D less F2C =3D FFLAGS =3D -O LIBCRUFT =3D -lcruft LIBGLOB =3D ../glob/glob.o ../glob/fnmatch.o LIBREADLINE =3D /usr/pkg/lib/libreadline.so RLD_FLAG =3D WITH_DL =3D true WITH_DYNAMIC_LINKING =3D true config_opts =3D --with-g77 --enable-shared --enable-rpath -prefix=3D/usr/= pkg --hos t=3Dsparc--netbsdelf --prefix=3D/usr/pkg includedir =3D /usr/pkg/include infodir =3D /usr/pkg/info libexecdir =3D /usr/pkg/libexec mandir =3D /usr/pkg/man F77 =3D cc FPICFLAG =3D -fPIC LIBFLAGS =3D -L.. LN_S =3D ln -s MKOCTFILE_INCFLAGS =3D -I/usr/pkg/include/octave-2.1.34 -I/usr/pkg/includ= e/octav e-2.1.34/octave -I/usr/pkg/include SHLEXT_VER =3D so.2.1.34 archlibdir =3D /usr/pkg/libexec/octave/2.1.34/exec/sparc--netbsdelf dld =3D 1 fcnfilepath =3D .:/usr/pkg/libexec/octave/2.1.34/site/oct/sparc--netbsdel= f//:/us r/pkg/libexec/octave/site/oct/sparc--netbsdelf//:/usr/pkg/share/octave/2.1.= 34/si te/m//:/usr/pkg/share/octave/site/m//:/usr/pkg/libexec/octave/2.1.34/oct/sp= arc-- netbsdelf//:/usr/pkg/share/octave/2.1.34/m// infofile =3D /usr/pkg/info/octave.info localverarchlibdir =3D /usr/pkg/libexec/octave/2.1.34/site/exec/sparc--ne= tbsdelf man1dir =3D /usr/pkg/man/man1 octlibdir =3D /usr/pkg/lib/octave-2.1.34 ALL_LDFLAGS =3D -L.. -u MAIN__ -fPIC -L/usr/pkg/lib -Wl,-R/usr/X11R6/li= b -L/us r/X11R6/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib DLFCN_INCFLAGS =3D LDFLAGS =3D -L/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -Wl,-R/= usr/pkg /lib -L/usr/pkg/lib RUNTEST =3D localstartupfiledir =3D /usr/pkg/share/octave/site/m/startup localveroctfiledir =3D /usr/pkg/libexec/octave/2.1.34/site/oct/sparc--net= bsdelf octfiledir =3D /usr/pkg/libexec/octave/2.1.34/oct/sparc--netbsdelf CC =3D cc CXXCPP =3D c++ -E LIBDLFCN =3D XTRA_CFLAGS =3D XTRA_CXXFLAGS =3D -fno-implicit-templates YFLAGS =3D -dv canonical_host_type =3D sparc--netbsdelf fcnfiledir =3D /usr/pkg/share/octave/2.1.34/m libdir =3D /usr/pkg/lib localoctfilepath =3D /usr/pkg/libexec/octave/2.1.34/site/oct/sparc--netbs= delf//: /usr/pkg/libexec/octave/site/oct/sparc--netbsdelf// localverfcnfiledir =3D /usr/pkg/share/octave/2.1.34/site/m man1ext =3D .1 prefix =3D /usr/pkg version =3D 2.1.34 INCFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../gl= ob -I.. /glob -I/usr/pkg/include LIBOCTINTERP =3D -loctinterp OCTAVE_LITE =3D false SH_LDFLAGS =3D SONAME_FLAGS =3D localarchlibdir =3D /usr/pkg/libexec/octave/site/exec/sparc--netbsdelf localfcnfilepath =3D /usr/pkg/share/octave/2.1.34/site/m//:/usr/pkg/share= /octave /site/m// } 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-03-26 13:20:14
|
On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote: | On Wed, 26 Mar 2003, Joao Cardoso wrote: ... | Inspired by your question and these results, I did a lot of | experimentation and finally found that if | | ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd | | is replaced by | | g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs | -lplplotd | | then all the linking problems disappear! So clearly, the netbsd | version of mkoctfile is set up improperly for that system: | | i.e., | | grep SH_LD `which mkoctfile` |grep '=' | | : ${SH_LD="ld"} | : ${SH_LDFLAGS=""} | | When it should have been the Linux result: | | grep SH_LD `which mkoctfile` | grep '=' | | : ${SH_LD="/usr/bin/g++"} | : ${SH_LDFLAGS="-shared"} | | Have you been able to build octave on your OSF1 system? I have not tried, but the system mkoctfile says: : ${SH_LD="c++"} : ${SH_LDFLAGS="-shared -Xlinker -expect_unresolved -Xlinker '*'"} Forget my other mail where I ask you to run octave_config_info. Only on octave versions 2.1xx is there information about SH_LD and SH_LDFLAGS. | I am trying | to get some idea (2 data points are more statistically significant | than 1 ...;-)) whether this is just a netbsd problem with mkoctfile | or are we going to have consistent problems when we use mkoctfile on | any Unix system other than Linux? Perhaps you should contact the package maintainer, or send a bug-report to the Octave lists. The second is not very likely to show results, as 2.1.xx is the main concern. 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 Canadian Centre for Climate | Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot | scientific plotting software package (plplot.org). | | __________________________ | | Linux-powered Science | __________________________ |
From: Alan W. I. <ir...@be...> - 2003-03-26 15:34:25
|
On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote: > | Have you been able to build octave on your OSF1 system? > > I have not tried, but the system mkoctfile says: > > : ${SH_LD=3D"c++"} > : ${SH_LDFLAGS=3D"-shared -Xlinker -expect_unresolved -Xlinker '*'"} At least these flags are not near-empty like on netbsd so there is some hop= e you will be able to build octave on OSF1. Anyhow, I suggest you do that experiment so that at least we can claim the octave interface to plplot works on at least one Unix system before the release. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-03-26 17:58:44
Attachments:
hello.cc
|
On Wednesday 26 March 2003 15:33, Alan W. Irwin wrote: | On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote: | > | Have you been able to build octave on your OSF1 system? | > | > I have not tried, but the system mkoctfile says: | > : ${SH_LD=3D"c++"} | > : ${SH_LDFLAGS=3D"-shared -Xlinker -expect_unresolved -Xlinker '*'"} | | At least these flags are not near-empty like on netbsd so there is | some hope you will be able to build octave on OSF1. I really don't know how the netbsd packager was able to link octave with=20 those options, as "g++" links with "-lstdc++", which "ld" does not. | Anyhow, I | suggest you do that experiment so that at least we can claim the | octave interface to plplot works on at least one Unix system before | the release. The problem is that the system has gcc-3.0.3 Octave 2.0.xx needs gcc-2.8/9.xx while octave-2.1.4x needs gcc > 3.0.x I tried to compile octave-2.0.17, 2.1.40 and 2.1.46. None succeeded. I could try to compile gcc-3.2.2, but I probably would need to compile=20 other tools as well. As I use this machine just to test Plplot, I don't=20 think it is worth the effort. If a system has octave, than it can have plplot_octave. This is for=20 sure. This is not true in this particular machine because the gcc version that=20 was used to compile octave (gcc-2.8.0) was removed by the system adm=20 when he upgrade to gcc-3.0.3 I could try to add a further test to configure, trying to compile a=20 hello.cc into a hello.oct, but I don't think it to be necessary. I attach a small file that you can try to compile in the bsd machine=20 with "mkoctfile hello.cc" and then call from octave as "hello". It=20 works in my system with octave-mkoctfile-2.0.16/17-2.1.36/43. If it works, then I will widthdraw my "This is for sure" comment above=20 :-) Joao |
From: Rafael L. <lab...@ps...> - 2003-03-26 07:18:19
|
* Alan W. Irwin <ir...@be...> [2003-03-25 17:02]: > This is still a showstopper with Rafael's patched debian version of > libtool. > > ./get-drv-info xwin > Segmentation fault (core dumped) What is the output of the following in netbsd: gdb ./get-drv-info run xwin bt ? -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-26 14:31:10
|
On Wed, 26 Mar 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-03-25 17:02]: > > > This is still a showstopper with Rafael's patched debian version of > > libtool. > > > > ./get-drv-info xwin > > Segmentation fault (core dumped) > > What is the output of the following in netbsd: > > gdb ./get-drv-info > run xwin > bt This was done with yesterday's system. I will report back later about what your latest changes do (which I assume will give the same information without having to use gdb). gdb ./get-drv-info GNU gdb 5.0nb1 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc--netbsdelf"... (gdb) run xwin Starting program: /home/irwin/plplot_working/drivers/./get-drv-info xwin Program received signal SIGSEGV, Segmentation fault. 0x126c0 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979 1979 if (dirname[dirname_len -1] == '/') (gdb) bt #0 0x126c0 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979 #1 0x12848 in find_module (handle=0xeffff5ec, dir=0x0, libdir=0x2e080 "/home/irwin/plplot_install/lib/plplot5.2.0.cvs.20030325/data/../driversd", dlname=0x28060 "xwin.so", old_name=0x0, installed=0) at ltdl.c:2045 #2 0x137a8 in try_dlopen (phandle=0xeffff65c, filename=0xe0 <Error reading address 0xe0: Invalid argument>) at ltdl.c:2823 #3 0x13cd8 in lt_dlopenext (filename=0xeffff9da "xwin") at ltdl.c:2983 #4 0x10fc4 in main (argc=2, argv=0xeffff9da) at get-drv-info.c:35 #5 0x10d44 in ___start () 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-26 15:05:43
|
* Alan W. Irwin <ir...@be...> [2003-03-26 06:29]: > This was done with yesterday's system. Thanks. > I will report back later about what your latest changes do (which I assume > will give the same information without having to use gdb). No, the informations are complementary. The signal handler in get-drv-info gives the description of the error, while the gdb backtrace gives the place where the problem happened. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-27 00:55:31
|
On Wed, 26 Mar 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-03-26 06:29]: > > I will report back later about what your latest changes do (which I assume > > will give the same information without having to use gdb). > > No, the informations are complementary. The signal handler in get-drv-info > gives the description of the error, while the gdb backtrace gives the place > where the problem happened. Here are the latest results with plplot-5.2.0.cvs.20030326.tar.gz and tcl/tk and freetype disabled. * All the mkoctfile configuration changes to compensate for the broken version on netbsd seem to be working. The warning message about this came through loud and clear during configuration, and plplot_octave.oct built without any obvious error messages. Thanks, Rafael! * Just noticed that Java configuration needs a tweak. Even though I used a default configuration (java not enabled), the java build went ahead in any case. I think the reason for the problem is lib_LTLIBRARIES = libplplotjava@LIB_TAG@.la appears outside the conditional. Do you agree, Rafael? * The only build problem was ./get-drv-info xwin libltdl error: can't open the module This is more informative than the segfault we had before, but I don't know how to interpret this message. Rafael? irwin@sparky gdb get-drv-info GNU gdb 5.0nb1 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc--netbsdelf"... (gdb) run xwin Starting program: /home/irwin/plplot_working/drivers/get-drv-info xwin Program received signal SIGSEGV, Segmentation fault. 0x12758 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979 1979 if (dirname[dirname_len -1] == '/') (gdb) bt #0 0x12758 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979 #1 0x128e0 in find_module (handle=0xeffff5ec, dir=0x0, libdir=0x2e080 "/home/irwin/plplot_install/lib/plplot5.2.0.cvs.20030326/data/../driversd", dlname=0x28060 "xwin.so", old_name=0x0, installed=0) at ltdl.c:2045 #2 0x13840 in try_dlopen (phandle=0xeffff65c, filename=0xe0 <Error reading address 0xe0: Invalid argument>) at ltdl.c:2823 #3 0x13d70 in lt_dlopenext (filename=0xeffff9d8 "xwin") at ltdl.c:2983 #4 0x1105c in main (argc=2, argv=0xeffff8c4) at get-drv-info.c:48 #5 0x10da4 in ___start () Rafael, I noticed this before, but forgot to ask; what does that Error reading address 0xe0: Invalid argument mean? Is the null argument for the filename argument for try_dlopen causing the segfault? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-27 06:11:24
|
* Alan W. Irwin <ir...@be...> [2003-03-26 16:54]: > Here are the latest results with plplot-5.2.0.cvs.20030326.tar.gz and > tcl/tk and freetype disabled. > > * All the mkoctfile configuration changes to compensate for the broken > version on netbsd seem to be working. The warning message about this > came through loud and clear during configuration, and plplot_octave.oct > built without any obvious error messages. Thanks, Rafael! Great. > * Just noticed that Java configuration needs a tweak. Even though I used a > default configuration (java not enabled), the java build went ahead in any > case. I think the reason for the problem is lib_LTLIBRARIES = > libplplotjava@LIB_TAG@.la appears outside the conditional. Do you agree, > Rafael? Sure. When I put things related to $(javagenfiles) outside the conditional, I accidentally put libplplotjava@LIB_TAG@.la too. This is a mistake and I will fix it. > * The only build problem was > > ./get-drv-info xwin > libltdl error: can't open the module > > This is more informative than the segfault we had before, but I don't know > how to interpret this message. > > Rafael? As I suspected, this is a problem with the linker in netbsd and its source may be elsewhere, not in the ltdl.c code. I have to think in a way to debug this. Unfortunately, I do not have an access to a netbsd system, so Alan will have to try my guesses. > Rafael, I noticed this before, but forgot to ask; what does that Error > reading address 0xe0: Invalid argument mean? Is the null argument for the > filename argument for try_dlopen causing the segfault? No idea. I will check this. -- Rafael |