From: Rafael L. <lab...@ps...> - 2003-01-28 10:38:23
Attachments:
plplot-5.2.0-autoheader.patch
|
I asked the question about unwanted calls to autoheader in the automake mailing list (aut...@gn...) and immediately somebody came with the solution. I prepared a patch (attached below) that should fix our problems and that keeps the separation of #defines between plConfig.h and plDevs.h as wished by Maurice. The patch is very small and changes the following files: 1) configure.ac: Defined AUTOHEADER="echo autoheader ignored". This is the magical thing, which gets propagated into the Makefile.in. With this, autoheader is never called when running make, not even by the developpers. Also, I changed the deprecated AM_CONFIG_HEADER to AC_CONFIG_HEADERS. 2) bootstrap.sh: Removed calls to "touch include/plConfig.h.in" and "autoheader". 3) include/plConfig.h.in: Removed all #undef PLD_*. since they are already in plDevs.h.in. I also strongly advise to remove that old acconfig.h from the CVS repository. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-30 02:38:43
|
On Tue, 28 Jan 2003, Rafael Laboissiere wrote: > 3) include/plConfig.h.in: > > Removed all #undef PLD_*. since they are already in plDevs.h.in. Sorry it has taken me a while to respond, but busy, busy! This part of your patch I don't quite understand. This file is currently generated by autoheader so it does not exist in CVS. Are you saying we should take the latest autoheader-generated version, put it under CVS control, and then make those recommended changes to get rid of the device stuff (as well as never running autoheader again under any circumstances)? If we run autoheader ever again after this file is edited, then I believe the device stuff will just come back again. 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-01-30 14:31:26
|
* Alan W. Irwin <ir...@be...> [2003-01-29 18:37]: > On Tue, 28 Jan 2003, Rafael Laboissiere wrote: > > > 3) include/plConfig.h.in: > > > > Removed all #undef PLD_*. since they are already in plDevs.h.in. > > This part of your patch I don't quite understand. This file is currently > generated by autoheader so it does not exist in CVS. Are you saying we > should take the latest autoheader-generated version, put it under CVS > control, and then make those recommended changes to get rid of the device > stuff (as well as never running autoheader again under any circumstances)? See my last reply to Maurice's message regarding the use of config.h.in. Yes, part of my proposal is to put plConfig.h.in under CVS control. This file would contain the user's space #defines, while config.h.in would be autoheader-generated (since only the first file given to AC_CONFIG_HEADERS is touched by autoheader). > If we run autoheader ever again after this file is edited, then I believe > the device stuff will just come back again. This happen in the current implementation because I did a poor implementation of header file processing in Autotools. With the new proposed scheme things will be much better. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-30 16:31:26
|
On Thu, 30 Jan 2003, Rafael Laboissiere wrote: > [...]while config.h.in would be > autoheader-generated (since only the first file given to AC_CONFIG_HEADERS > is touched by autoheader). > > [...] With the new > proposed scheme things will be much better. Thanks for answering my previous question, but now I have one more. How do you avoid autoheader automatically putting all the device stuff in config.h.in (like it does now for plConfig.h.in)? 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-01-30 21:06:48
|
* Alan W. Irwin <ir...@be...> [2003-01-30 08:30]: > Thanks for answering my previous question, but now I have one more. How do > you avoid autoheader automatically putting all the device stuff in > config.h.in (like it does now for plConfig.h.in)? There is no way to avoid that, but this is completely harmless. Many #defines will be duplicated in both config.h and plConfig.h, but since they are not redefined to different values, not even a warning message is issued by the compiler (I checked that with gcc -Wall). And now the good news: I have already an almost working patch to HEAD that should fix all (or almost all) autoheader related problems. I am only waiting the #defines list to be kept in plConfig.h to proceed. Maurice? If that works, I hope that the autotrolls here will stop pestering for a while ;-) -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-01-30 22:03:19
Attachments:
plplot-autoheader.patch
plConfig.h.in
|
* Rafael Laboissiere <lab...@ps...> [2003-01-30 21:57]: > And now the good news: I have already an almost working patch to HEAD that > should fix all (or almost all) autoheader related problems. I am only > waiting the #defines list to be kept in plConfig.h to proceed. Maurice? The promised patch is attached below. It is not yet fully test, but at least bootstrap.sh works (both autoconf and autoheader). I am also attaching the new include/plConfig.h.in file, but its contents may change. acconfig.h must be deleted from and include/plConfig.h.in must be added to the CVS repository. Here is a summary of the changes: * In configure.ac, AM_CONFIG_HEADER is replaced by AC_CONFIG_HEADERS. config.h is now the first element in the arguments list. * All AC_DEFINE and AC_DEFINE_UNQUOTED macros in configure.ac and sysloc.in have now three arguments, as mandated by the autoheader docs. * Added at the top of plConfig.h: #if HAVE_CONFIG_H # include <config.h> #endif * The strange call touch plDevs.h in bootstrap.sh has been removed. Could you please check if this patch is okay? -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-31 00:52:05
|
On Thu, 30 Jan 2003, Rafael Laboissiere wrote: > The promised patch is attached below. It is not yet fully test, but at > least bootstrap.sh works (both autoconf and autoheader). I am also > attaching the new include/plConfig.h.in file, but its contents may change. > acconfig.h must be deleted from and include/plConfig.h.in must be added to > the CVS repository. > > Here is a summary of the changes: > > * In configure.ac, AM_CONFIG_HEADER is replaced by AC_CONFIG_HEADERS. > config.h is now the first element in the arguments list. > > * All AC_DEFINE and AC_DEFINE_UNQUOTED macros in configure.ac and > sysloc.in have now three arguments, as mandated by the autoheader docs. > > * Added at the top of plConfig.h: > > #if HAVE_CONFIG_H > # include <config.h> > #endif > > * The strange call touch plDevs.h in bootstrap.sh has been removed. > > > Could you please check if this patch is okay? The patch applies cleanly on top of my recent changes to sysloc.in and configure.ac. I do get one error message, however, from bootstrap.sh. configure.ac:770: required file ./config.h.in' not found Also, no config.h.in (or config.h) is produced. The workaround was to put touch config.h.in in bootstrap.sh. Once that was done, there were absolutely no messages from bootstrap.sh which is a first for me, and quite encouraging. I then went on with configure; make; make install, and all was well with plplot-test.sh (produced identical postscript to 5.2.0). So I am committing it because it is no worse than before, and I like the fact that all those stupid warnings are gone. BTW, have a look at Rafael's extensive comments in the include/plConfig.in.h log for the AM-LT branch. (That file existed on that branch for a while before it was deleted for that branch. Apparently when I used cvs add on the current file, the state information is okay since I can retrieve it from CVS without problems.) Rafael's cvs log comments are very similar to recent threads explaining why the bizarre touch command has to be used in ./bootstrap.sh, etc. Now for the bad news. The current commit does not solve the fundamental problem that started all this thread: Right in the middle of my initial make: cd .. && /bin/sh /home/software/plplot_cvs/HEAD/plplot/missing --run autoheader touch ./plDevs.h.in UGH! Part of what is going on is the CVS date of ./plDevs.h.in is fixed in December. So this touch occurs when you first make, and you are okay until the next time you do a CVS update (which I believe restores the old date). plConfig.h.in is currently okay because the CVS date is today. But if configure.ac is updated again, then make will assume plConfig.h.in is out of date and will run autoheader on it as well. Note, I am no longer using the Debian autotools which have been patched extensively by the Debian packager to allow a combination of old and new autoconf stuff. Instead, in the interests of making sure we all have the same autotools versions, I have been using the latest stable releases of everything, (autoconf-2.57, automake-1.7.2, and libtool-1.4.3) which I downloaded from FSF and built from scratch. I think we have clearly run up against a bug in autoconf since autoheader is not supposed to be run on those files at all. (It is only supposed to be used to generate files from scratch such as config.h.in, not modify existing files, and besides these are the second and third files in the list for AC_CONFIG_HEADERS, and the documentation says autoheader should only be invoked for the first file.) Rafael, in your first post you had a suggestion for supressing autoheader altogether. Perhaps it is time to try that as a workaround for the bug. But I am amazed (a) this problem hasn't bitten most of the many projects that are using autoconf and cvs together, and (b) the resulting outcry didn't generate strong motivation for a quick fix. 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-01-31 03:11:59
|
On Thu, 30 Jan 2003, Alan W. Irwin wrote: > I think we have clearly run up against a bug in autoconf since autoheader is > not supposed to be run on those files at all. (It is only supposed to be > used to generate files from scratch such as config.h.in, not modify existing > files, and besides these are the second and third files in the list for > AC_CONFIG_HEADERS, and the documentation says autoheader should only be > invoked for the first file.) > > Rafael, in your first post you had a suggestion for supressing autoheader > altogether. I have just (tentatively) committed that workaround as a basis for discussion and testing. (Also, I have moved AC_CONFIG_HEADERS right after AC_INIT as the documentation says to do, but it made no difference, and the bug still exists for that case.) What the redefinition means is that autoheader is turned into the command: "echo autoheader ignored" throughout all Makefiles. So effectively autoheader can never be invoked from the make command even in those cases (e.g., config.h.in) where it *should* be invoked (i.e., whenever configure.ac is changed, config.h.in should be regenerated, and now that won't happen automatically using the make command. However, you can arrange it to happen from ./bootstrap.sh, and I think that is good enough. Actually I am not sure if rm -f is cross-platform so I touch; rm; touch to get a fresh zero-length file which is then replaced by autoheader run from ./bootstrap.sh.) Anyhow, I have also committed the ./bootstrap.sh change as a basis for further discussion and testing. Note, in my tests so far configure outputs the message that config.h is unchanged (with the same old date). There are similar messages for include/plConfig.h and include/plDevs.h. So I think these bug workarounds are doing the right thing with respect to making gratuitous date changes to header files if none of the symbols have been changed. However, the gratuitous touching of include/plConfig.h.in and include/plDevs.h.in is a bit of a pain with regard to the CVS messages about what files have been recently updated when you are trying to commit something. But I can live with that until the autoconf/autoheader bug is fixed. (In the back of my mind I can visualize thousands of projects using this "echo autoheader ignored" workaround rather than putting on the pressure to get the stupid bug fixed.) But I hasten to add I also am unwilling to submit a bug report at this time because I simply don't have the time. To do it right you would make a really simple fake "hello world" project with a couple of defines and then see whether autoheader is invoked appropriately or not. Anyhow, I think we have a tentative solution (thanks mostly to Rafael). Of course it will require extensive testing. Furthermore, there are still more problems to solve. For example, I noticed a warning message from configure: checking for itcl.h... /usr/include/tcl8.3/itcl-private/generic/itcl.h checking itclDecls.h usability... no checking itclDecls.h presence... yes configure: WARNING: itclDecls.h: present but cannot be compiled configure: WARNING: itclDecls.h: check for missing prerequisite headers? configure: WARNING: itclDecls.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug...@gn.... ## configure: WARNING: ## ------------------------------------ ## checking for itclDecls.h... yes Something seems really screwed up there. Maurice, since you worked on that aspect of the configuration before, can you sort this out? Also, all sorts of X configuration is currently done in sysloc.in, and much like the python case I just completed I would rather use the automake macros to configure X to simplify what we do if that is at all possible. Also, there is the issue of static drivers which seemed to fail on all platforms other than Debian. I will make sure they work both for RH7.3 and the limited solaris system I have access to, but after that I rely on the rest of the developers to test my fix (assuming the problem shows for one of those two platforms) on all your accessible platforms. Are there any other configuration changes anybody wants to tackle before 5.2.1 comes out? Currently, I am thinking of releasing 5.2.1 on 1 March which gives roughly 4 weeks for us to improve the configuration and hammer the result with a variety of tests on a variety of platforms so we don't get egg on our face again. However, that date is just a suggestion at this point. If some of the issues I mentioned above take longer than expected to fix we may have to delay the release until even later. 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-01-31 13:01:28
|
* Alan W. Irwin <ir...@be...> [2003-01-30 19:10]: > (In the back of my mind I can visualize thousands of projects using this > "echo autoheader ignored" workaround rather than putting on the pressure to > get the stupid bug fixed.) But I hasten to add I also am unwilling to > submit a bug report at this time because I simply don't have the time. Please, do not submit a bug report to the autoconf developers, since there is no bug here (see my last message). Our configuration system and our way to generate tarball is currently broken and my proposed changes will improve the situation. That "echo autoheader ignored" workaround is an ugly thing and I doubt that people out there adopt it. > Also, all sorts of X configuration is currently done in sysloc.in, and much > like the python case I just completed I would rather use the automake > macros to configure X to simplify what we do if that is at all possible. This is a good idea. We should try to use standard approaches when they exist. For instance, why not starting using /usr/share/aclocal/tcl.m4 instead of that complete messy code for Tcl/Tk configuration in sysloc.in? > Also, there is the issue of static drivers which seemed to fail on all > platforms other than Debian. I will make sure they work both for RH7.3 and > the limited solaris system I have access to, but after that I rely on the > rest of the developers to test my fix (assuming the problem shows for one > of those two platforms) on all your accessible platforms. Unless I have access to a non-Debian system (which I don't) I cannot help here. The bug report sent by Doug Hunt to the plplot-devel is very terse and I have no clue about the origin of the problem. > Are there any other configuration changes anybody wants to tackle before > 5.2.1 comes out? One thing that we must try to achieve is to make "make dist" produce a suitable tarball. Otherwise, I have a couple of small ideas on how to improve PLplot such that packaging for Debian (and probably for other distros) will be much better. By the way, I would like to merge the DEBIAN branch into HEAD before 5.2.1 comes out. I had hold on that because I had to make too many changes to our pre-AT configuration scheme for Debian. > Currently, I am thinking of releasing 5.2.1 on 1 March which gives roughly > 4 weeks for us to improve the configuration and hammer the result with a > variety of tests on a variety of platforms so we don't get egg on our face > again. However, that date is just a suggestion at this point. If some of > the issues I mentioned above take longer than expected to fix we may have > to delay the release until even later. I will be unavailable during part of February, so this schedule will not suit me the best. April 1 would be much better, but that may become unacceptably late. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-31 16:57:44
|
On Fri, 31 Jan 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-01-30 19:10]: > > Also, all sorts of X configuration is currently done in sysloc.in, and much > > like the python case I just completed I would rather use the automake > > macros to configure X to simplify what we do if that is at all possible. > > This is a good idea. We should try to use standard approaches when they > exist. For instance, why not starting using /usr/share/aclocal/tcl.m4 > instead of that complete messy code for Tcl/Tk configuration in sysloc.in? I won't have time/expertise to look at that Tcl/Tk-specific one myself, but it would be great if Maurice would....;-) > > Are there any other configuration changes anybody wants to tackle before > > 5.2.1 comes out? > > One thing that we must try to achieve is to make "make dist" produce a > suitable tarball. Otherwise, I have a couple of small ideas on how to > improve PLplot such that packaging for Debian (and probably for other > distros) will be much better. By the way, I would like to merge the DEBIAN > branch into HEAD before 5.2.1 comes out. That merge would be great. Just watch out for zombied files with bad CVS state information! I think I got them all, but a merge tests that completely. > > Currently, I am thinking of releasing 5.2.1 on 1 March which gives roughly > > 4 weeks for us to improve the configuration and hammer the result with a > > variety of tests on a variety of platforms so we don't get egg on our face > > again. However, that date is just a suggestion at this point. If some of > > the issues I mentioned above take longer than expected to fix we may have > > to delay the release until even later. > > I will be unavailable during part of February, so this schedule will not > suit me the best. April 1 would be much better, but that may become > unacceptably late. No, that is fine with me (or actually a weekend later). My current job ends on 31 March so the difference for me between March 1st and April 1st is 4 time-pressured weekends where I will probably be involved in a last-minute job-finishing rush while from April 1st to April 5th gives me a lot more time to concentrate on the testing and release. So how does Saturday, April 5th sound to the rest of you? Alan |
From: Maurice L. <mj...@ga...> - 2003-02-01 05:47:07
|
Alan W. Irwin writes: > On Fri, 31 Jan 2003, Rafael Laboissiere wrote: > > This is a good idea. We should try to use standard approaches when they > > exist. For instance, why not starting using /usr/share/aclocal/tcl.m4 > > instead of that complete messy code for Tcl/Tk configuration in sysloc.in? > > I won't have time/expertise to look at that Tcl/Tk-specific one myself, but > it would be great if Maurice would....;-) Another one for the great list. But if you tire of waiting on me, you know what to do! :) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2003-02-01 05:44:08
|
Alan W. Irwin writes: > Furthermore, there are still more problems to solve. For example, I noticed > a warning message from configure: > > checking for itcl.h... /usr/include/tcl8.3/itcl-private/generic/itcl.h > checking itclDecls.h usability... no > checking itclDecls.h presence... yes > configure: WARNING: itclDecls.h: present but cannot be compiled > configure: WARNING: itclDecls.h: check for missing prerequisite headers? > configure: WARNING: itclDecls.h: proceeding with the preprocessor's result > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to bug...@gn.... ## > configure: WARNING: ## ------------------------------------ ## > checking for itclDecls.h... yes > > Something seems really screwed up there. Maurice, since you worked on that > aspect of the configuration before, can you sort this out? Ugh. I looked into this a while back and decided it was innocuous. It sure is ugly though.. so would be good to fix eventually. On the infinite list. :) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-01-31 12:26:37
Attachments:
java-python-nodist.patch
|
* Alan W. Irwin <ir...@be...> [2003-01-30 16:50]: > The patch applies cleanly on top of my recent changes to sysloc.in and > configure.ac. I do get one error message, however, from bootstrap.sh. > > configure.ac:770: required file ./config.h.in' not found This bug is extremely easy to fix: just invert the order of calls to autoheader and automake in bootstrap.sh, like this: aclocal \ && libtoolize --copy --ltdl --automake \ && autoheader \ && automake --add-missing --copy \ && autoconf The problem happens because the automake call tries to run autoconf and then it barfs on the AC_CONFIG_HEADERS macro, since config.h.in has not yet been created by autoheader. The "touch config.h.in" workaround is ugly and unnecessary, and if you agree I will cvs commit the fixed bootstrap.sh. > Now for the bad news. The current commit does not solve the fundamental > problem that started all this thread: > > Right in the middle of my initial make: > > cd .. && /bin/sh /home/software/plplot_cvs/HEAD/plplot/missing --run autoheader touch ./plDevs.h.in > > UGH! Well, you have been bitten by the fact that you are not using "make dist" to generate the tarball. Had you used "make dist", the tarball would have the right time stamps (thanks to that touch command in include/Makefile). Check for yourself: $ rm -rf plplot $ cvs co plplot # your CVSROOT env var should be set correctly here $ cd plplot $ ls -lt configure.ac include/plConfig.h.in include/plDevs.h.in -rw-r--r-- 1 rafael rafael 30417 2003-01-31 02:49 configure.ac -rw-r--r-- 1 rafael rafael 1249 2003-01-31 01:15 include/plConfig.h.in -rw-r--r-- 1 rafael rafael 1056 2002-12-03 09:39 include/plDevs.h.in $ # configure.ac is newer than include/pl{Config,Devs}.h !!!!! $ ./bootstrap.sh $ ./configure $ make dist $ tar xfz plplot-5.2.0.tar.gz $ cd plplot-5.2.0 $ ls -lt configure.ac include/plConfig.h.in include/plDevs.h.in -rw-r--r-- 1 rafael rafael 1056 2003-01-31 13:00 include/plDevs.h.in -rw-r--r-- 1 rafael rafael 1249 2003-01-31 13:00 include/plConfig.h.in -rw-r--r-- 1 rafael rafael 30421 2003-01-31 12:58 configure.ac $ # Now configure.ac is the oldest file. Great! As I already discussed privately with Alan, we must _absolutely_ use "make dist" for generating the distribution tarball, otherwise there will be recurrent problems like that with our releases. Since Alan is reluctant to make the move, I volunteer myself to insure that "make dist" will produce a suitable and complete tarball for the 5.2.1 release. The other (boring) release engineering issues (like tests, etc), I will let to Alan, of course :-) Just an aside comment: "make dist" does not work in the current CVS tree because nodist_ prefixes are lacking in binding/{python,java}/Makefile.am. Attached below is the patch that fixes the problem. This patch is harmless when building the package and I am going to cvs commit it, if you do not object. > I think we have clearly run up against a bug in autoconf since autoheader is > not supposed to be run on those files at all. With my changes to bootstrap.sh and the tarball being generated by "make dist", everything should be fine. The call to autoheader is harmless now, since the autoheader issues have been addressed. Besides, it will never happen for regular users if we adopt the "make dist" approach. I hope to go from Hell to Paradise with the forthcoming 5.2.1 release! > Rafael, in your first post you had a suggestion for supressing autoheader > altogether. Perhaps it is time to try that as a workaround for the bug. Forget that. The autoheader call should work fine now. In sum, there is no bug to be fixed here. I will soon remove that setting to AUTOHEADER in autoconf.ac and cvs commit if you do not object. > But I am amazed (a) this problem hasn't bitten most of the many projects > that are using autoconf and cvs together, and (b) the resulting outcry > didn't generate strong motivation for a quick fix. Again: there is no bug here. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-31 16:35:14
|
On Fri, 31 Jan 2003, Rafael Laboissiere wrote: > As I already discussed privately with Alan, we must _absolutely_ use "make > dist" for generating the distribution tarball, otherwise there will be > recurrent problems like that with our releases. Since Alan is reluctant to > make the move, I volunteer myself to insure that "make dist" will produce a > suitable and complete tarball for the 5.2.1 release. That would be great, Rafael. If the result passes the plplot-test.sh test, then I would be happy. > Just an aside comment: "make dist" does not work in the current CVS tree > because nodist_ prefixes are lacking in binding/{python,java}/Makefile.am. > Attached below is the patch that fixes the problem. This patch is harmless > when building the package and I am going to cvs commit it, if you do not > object. One of my weaknesses is I am probably too oriented to results and not to design. But the upside of that is I am open to design changes so long as the result works. So yes please go ahead and make any required changes so that make dist works properly. > I hope to go from Hell to Paradise with the forthcoming 5.2.1 release! Sounds good to me! 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-01-31 17:03:29
|
* Alan W. Irwin <ir...@be...> [2003-01-31 08:34]: > So yes please go ahead and make any required changes so that make dist > works properly. Okay, I will cvs commit these and the autoheader-related changes that I mentioned in a previous post over the weekend. -- Rafael |
From: <jc...@fe...> - 2003-01-31 15:08:35
|
On Friday 31 January 2003 12:51, Rafael Laboissiere wrote: =2E.. | > Also, there is the issue of static drivers which seemed to fail on | > all platforms other than Debian. I will make sure they work both | > for RH7.3 and the limited solaris system I have access to, but | > after that I rely on the rest of the developers to test my fix | > (assuming the problem shows for one of those two platforms) on all | > your accessible platforms. This is not quite true, since static drivers work in SuSE-8.1 (with the=20 5.2.0 tarball). What I have advised users to do is to use dyndrivers,=20 as that is the more tested configuration. There is however something that can be confusing, perhaps not only for=20 users but also for libtool: there is the standard --enable-shared and=20 our own --with-shlibs. If I specify only --disable-shared, at the end in the configure summary=20 appears --with-shlibs=3Dyes. To be sure, I have specified both =20 --disable-shared and --without-shlib, and after make and make install=20 only static libs where installed, no drivers where installed and x01c=20 has more than 1.6MB and runs OK. | Unless I have access to a non-Debian system (which I don't) I cannot | help here. The bug report sent by Doug Hunt to the plplot-devel is | very terse and I have no clue about the origin of the problem. | | > Are there any other configuration changes anybody wants to tackle | > before 5.2.1 comes out? - I would like to drop the --with-shlibs option and use only the=20 standard --enable-shared. - --enable-dyndrivers should be the default, as it is the more tested=20 configuration. - --with-double should be the default, as most users seems to use it. - with-debug should be the default. This is the standard and will help=20 us to trace user reported segfaults/core-dumps. Joao |
From: Rafael L. <lab...@ps...> - 2003-01-31 16:03:58
|
* João Cardoso <jc...@fe...> [2003-01-31 15:09]: > If I specify only --disable-shared, at the end in the configure summary > appears --with-shlibs=yes. To be sure, I have specified both > --disable-shared and --without-shlib, and after make and make install only > static libs where installed, no drivers where installed and x01c has more > than 1.6MB and runs OK. I am relieved to know that static drivers buidl correctly in non-Debian systems. Thanks for the info. > - I would like to drop the --with-shlibs option and use only the > standard --enable-shared. > > - --enable-dyndrivers should be the default, as it is the more tested > configuration. > > - --with-double should be the default, as most users seems to use it. > > - with-debug should be the default. This is the standard and will help > us to trace user reported segfaults/core-dumps. I second these four proposed changes. -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-02-01 05:45:31
|
Jo=E3o Cardoso writes: > - I would like to drop the --with-shlibs option and use only the=20 > standard --enable-shared. >=20 > - --enable-dyndrivers should be the default, as it is the more test= ed=20 > configuration. >=20 > - --with-double should be the default, as most users seems to use it= . No problem here. > - with-debug should be the default. This is the standard and will he= lp=20 > us to trace user reported segfaults/core-dumps. Here too, although note --with-debug currently doesn't do anything. Autoconf emits "-g -O2" for gcc by default and appears to use "-g" for other compilers. Again, this is something on my list of things to address when there is time. --=20 Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (= RIST) |