Menu
▾
▴
plplot-devel
|
From: Maurice L. <mj...@ga...> - 2002-12-22 19:50:30
|
Getting started: I built & installed tcl, tk, itcl, BLT, into a new directory ~/tools to be used as prefix for these tests. Then made a tar copy of it in its pristine state so I could blow it away and start fresh as needed. Fresh checkout of plplot from HEAD. Note I have little prior experience with AM/LT and am just trying to follow the prescription and otherwise figure things out as I go along. I'm currently stumped (see 3b) so please see that first then look at the rest at your leisure. 1. Running bootstrap. Ran into problems with my existing versions of autoconf, automake, and libtool. They were all versions at or beyond what was given in http://sourceforge.net/mailarchive/forum.php?thread_id=1375571&forum_id=2199, but apparently not sufficiently in sync with each other. But that's a problem for lots of packages (certain versions of itcl only working with certain versions of tcl, etc). The first time I got: ged$ ./bootstrap.sh aclocal: configure.ac: 474: macro `AM_PATH_PYTHON' not found in library and after upgrading automake, then: ged$ ./bootstrap.sh aclocal: configure.ac: 430: macro `AM_PROG_LIBTOOL' not found in library So I upgraded to all the latest stable versions: autoconf-2.57.tar.gz automake-1.7.tar.gz libtool-1.4.3.tar.gz and finally got through a bootstrap.sh OK, albeit with the following messages: ged$ ./bootstrap.sh WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. 2. configuration issues. a) (OLD PROBLEM) Get this under newer versions of autoconf: 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: ## ------------------------------------ ## b) (OLD PROBLEM) checking for tclInt.h... no warning: can't find tclInt.h, setting enable_tkwin to no c) (OLD PROBLEM) This is wrong, since I do have libvga: checking for libvga... no warning: can't find libvga, setting enable_linuxvga to no d) (NEW PROBLEM) Problem finding vfork.h: checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no e) (NEW PROBLEM) It doesn't find my KAI C++ compiler: CXX: g++ My code to do this was previously in cf/sysconf.in, which doesn't appear to be used any more. Explanation? Just curious, I should be able to suck in that code by trial and error. 3. The build. a) Went mostly well but it sure is busy! I previously had code to eliminate redundant -I options but unfortunately that's not there any more, making the build a lot less clean looking (i.e. harder to see what's going on). E.g. in this case the compile has 1 redundant -I../../include and 2 redundant -I/home/mjl/tools/include. gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl -I/home/mjl/tools/include -I/home/mjl/tools/include -I/home/mjl/tools/include -g -O2 -MT tkMain.lo -MD -MP -MF .deps/tkMain.Tpo -c ../tk/tkMain.c -o tkMain.o >/dev/null 2>&1 The link also would have redundant -L options, but it looks like libtool is filtering them out. b) Problem building libplplottcltk: /bin/sh ../../libtool --mode=link gcc -g -O2 -o libplplottcltk.la -rpath /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib -no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2 -L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src -lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo tkMain.lo rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.* gcc -shared tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo tkMain.lo -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath -Wl,/home/mjl/tools/lib -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3 -litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src /home/mjl/dev/plplot/latest/src/.libs/libplplot.so /home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so -Wl,-soname -Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0 /usr/bin/ld: cannot find -litcl3.2 collect2: ld returned 1 exit status make[2]: *** [libplplottcltk.la] Error 1 Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from libtool, but I have no idea why. c) What's the deal with all the weird suffices? .lo .la .lai -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-22 20:38:24
|
Maurice LeBrun writes: > 3. The build. > ... > b) Problem building libplplottcltk: > > /bin/sh ../../libtool --mode=link gcc -g -O2 -o libplplottcltk.la -rpath > /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib > -no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2 > -L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src > -lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo > tcpip.lo tkMain.lo > > rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.* > > gcc -shared tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo > tkMain.lo -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath > -Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath > -Wl,/home/mjl/tools/lib -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3 > -litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src > /home/mjl/dev/plplot/latest/src/.libs/libplplot.so > /home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so -Wl,-soname > -Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0 > /usr/bin/ld: cannot find -litcl3.2 > collect2: ld returned 1 exit status > make[2]: *** [libplplottcltk.la] Error 1 > > Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from > libtool, but I have no idea why. Here's another example of $prefix/lib (in this case /home/mjl/tools/lib) being "lost" in the link line: /bin/sh ../../libtool --mode=link gcc -g -O2 -o libtclmatrix.la -rpath /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib -no-undefined -L /home/mjl/tools/lib -ltcl8.3 tclMatrix.lo matrixInit.lo rm -fr .libs/libtclmatrix.la .libs/libtclmatrix.* .libs/libtclmatrix.* gcc -shared tclMatrix.lo matrixInit.lo -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3 -Wl,-soname - Wl,libtclmatrix.so.5 -o .libs/libtclmatrix.so.5.1.0 Not good, as the version I have of tcl8.3 under $prefix/lib is the one I want to link against, and this line causes the tcl lib under /usr/lib to be used instead. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-12-22 22:14:51
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote: > Maurice LeBrun writes: > Here's another example of $prefix/lib (in this case /home/mjl/tools/lib) > being "lost" in the link line: I think it is again a problem with the leading blank in the path string. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Alan W. I. <ir...@be...> - 2002-12-22 22:11:50
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote: > b) Problem building libplplottcltk: > > /bin/sh ../../libtool --mode=link gcc -g -O2 -o libplplottcltk.la -rpath > /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib > -no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2 > -L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src > -lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo > tcpip.lo tkMain.lo > > rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.* > > gcc -shared tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo > tkMain.lo -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath > -Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath > -Wl,/home/mjl/tools/lib -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3 > -litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src > /home/mjl/dev/plplot/latest/src/.libs/libplplot.so > /home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so -Wl,-soname > -Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0 > /usr/bin/ld: cannot find -litcl3.2 > collect2: ld returned 1 exit status > make[2]: *** [libplplottcltk.la] Error 1 > > Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from *********************************^ > libtool, but I have no idea why. I will answer the rest later, but to get you started again, it looks like there is a blank between the -L option and the path. I think they have to be jammed together (at least that is what man ld says). So there is probably some problem with sysloc.in (or configure.ac) that inserts a blank prefix in the path. In my case I am using default library locations for the tcl/tk libraries so I don't exercise that logic. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-22 22:21:53
|
Alan W. Irwin writes: > I will answer the rest later, but to get you started again, it looks like > there is a blank between the -L option and the path. I think they have to > be jammed together (at least that is what man ld says). So there is > probably some problem with sysloc.in (or configure.ac) that inserts a blank > prefix in the path. In my case I am using default library locations for the > tcl/tk libraries so I don't exercise that logic. That did the trick, thanks. Hmm.. I seem to recall that some systems permit there to be a blank. Anyway, onward ho. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-22 22:25:41
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > I will answer the rest later, but to get you started again, it looks like > > there is a blank between the -L option and the path. I think they have to > > be jammed together (at least that is what man ld says). So there is > > probably some problem with sysloc.in (or configure.ac) that inserts a blank > > prefix in the path. In my case I am using default library locations for the > > tcl/tk libraries so I don't exercise that logic. > > That did the trick, thanks. Hmm.. I seem to recall that some systems permit > there to be a blank. Anyway, onward ho. Oh.. just realized that it was *libtool* that wasn't handling the blank properly, as the -L <place> stanza just vanished after processing with libtool. ld would've handled it ok, even though it's not documented in the man page (I just tried). -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-22 22:30:36
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Alan W. Irwin writes: > > > I will answer the rest later, but to get you started again, it looks like > > > there is a blank between the -L option and the path. I think they have to > > > be jammed together (at least that is what man ld says). So there is > > > probably some problem with sysloc.in (or configure.ac) that inserts a blank > > > prefix in the path. In my case I am using default library locations for the > > > tcl/tk libraries so I don't exercise that logic. > > > > That did the trick, thanks. Hmm.. I seem to recall that some systems permit > > there to be a blank. Anyway, onward ho. > > Oh.. just realized that it was *libtool* that wasn't handling the blank > properly, as the -L <place> stanza just vanished after processing with > libtool. ld would've handled it ok, even though it's not documented > in the man page (I just tried). The problem's in configure.ac.. I'm fixing it now. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-22 23:00:42
|
Some more comments: - we probably should stop installing this under $prefix/lib/plplot5.1.0, since it's a far cry from 5.1.0. We should probably adopt some convention in this area to avoid getting burned, but I'm not sure what it should be. Room for discussion here.. - nothing's being put in $prefix/share any more. Previously: ged$ ls ~/gts/share/plplot/ CHANGES COPYING.LIB Copyright FAQ NEWS README README.local ToDo mklinks* Yeah a lot of that stuff is ancient, but some of it has to stay like COPYING.LIB and Copyright. - my nice little "reconfig" script is no longer being created :(. I use it to not have to remember what configure arguments I gave. Also previously it was used to automatical reconfigure when the makefile got out of date wrt the configuration files, but it looks like AM/LT might do this automatically. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-12-23 00:24:27
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote: > Some more comments: > > - we probably should stop installing this under $prefix/lib/plplot5.1.0, > since it's a far cry from 5.1.0. We should probably adopt some convention > in this area to avoid getting burned, but I'm not sure what it should be. > Room for discussion here.. There are at least three issues to discuss with regard to version. (1) What should the library version be? Traditionally, we have made it the same as the package version, but that is not necessary, and according to libtool info is actively discouraged. I don't care about this issue, but a conscious decision should be made. (2) What should the package version be? I vote for 5.2.0 rather than 6.0.0 just because I want to conserve numbers. There are lots of major changes in our future so I don't want to start running into double-digit major numbers any sooner than we have to. The other issue, is that from the Linux user perspective there is not much major change in this version. Under the hood there is of course major change with the new configuration system, but once the version is installed (i.e., what a binary rpm or deb user will see) the user won't notice huge changes. (3) How do we implement what is decided? Rafael, I just followed what you did, but I am mostly lost here about exactly what is happening. All I know is that PLPLOT_VERSION no longer worked and you replaced it by VERSION (which did work) in the subset of the code you were dealing with. I just followed this lead and continued that replacement wherever I encountered PLPLOT_VERSION, but I don't know how, for example, to set VERSION to 5.2.0. How, would you do that? Also, I don't understand how setting SOVERSION to 6:0:1 in configure.ac then forces all our current library versions to be 5.1.0. That is really strange, but it does work. How would you change our library version to 5.2.0 (or 1.0.0 if we decided to start fresh here with library versions, see issue 1 above)? Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-23 04:54:26
|
Alan W. Irwin writes: > (2) What should the package version be? I vote for 5.2.0 rather than 6.0.0 > just because I want to conserve numbers. There are lots of major changes in > our future so I don't want to start running into double-digit major numbers > any sooner than we have to. The other issue, is that from the Linux user > perspective there is not much major change in this version. Under the hood > there is of course major change with the new configuration system, but once > the version is installed (i.e., what a binary rpm or deb user will see) the > user won't notice huge changes. I think we should go to 5.99a, then after that 5.99b, 5.99c, etc. When the package is finally completely stable then release it as 6.0. :-P -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-12-23 05:39:38
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote: > I think we should go to 5.99a, then after that 5.99b, 5.99c, etc. > When the package is finally completely stable then release it as 6.0. > > :-P Sounds like an excellent plan. Although to be consistent we should continue the sequence all the way to 5.99j and then arbitrarily declare the next version as 6.0....;-) Alan P.S. Thank God for that smiley on your "modest proposal". Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Alan W. I. <ir...@be...> - 2002-12-22 23:21:54
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote: > 1. Running bootstrap. > So I upgraded to all the latest stable versions: > > autoconf-2.57.tar.gz > automake-1.7.tar.gz > libtool-1.4.3.tar.gz > > and finally got through a bootstrap.sh OK Debian packagers of the stable version (which I have) often bring in fixes from later versions, and in autoconf's case revert to autoconf 2.13 if there is some problem. So you end up with something non-standard (except for Debian) which works very well. But it sure doesn't give you much guidance on what versions of packages you should recommend to your friends. So I am glad you found this clean combination of the latest/greatest that works. Everybody should write down those version numbers for future reference. > albeit with the following > messages: > > ged$ ./bootstrap.sh > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > WARNING: and `config.h.top', to define templates for `config.h.in' > WARNING: is deprecated and discouraged. > > WARNING: Using the third argument of `AC_DEFINE' and > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > WARNING: `acconfig.h': > > WARNING: AC_DEFINE([NEED_MAIN], 1, > WARNING: [Define if a function `main' is needed.]) > > WARNING: More sophisticated templates can also be produced, see the > WARNING: documentation. I also get those same messages which appear to be harmless, but I hope somebody knows how to get rid of them at some stage. I also get a few more messages tacked on the end: configure.ac:708: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst configure.ac:890: warning: do not use m4_regexp: use regexp or m4_bregexp autoheader2.50: include/plConfig.h.in' is unchanged Again, I hope somebody can get rid of these, but they appear to be harmless. > 2. configuration issues. > > a) (OLD PROBLEM) Get this under newer versions of autoconf: > > 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: ## ------------------------------------ ## > > > b) (OLD PROBLEM) > > checking for tclInt.h... no > warning: can't find tclInt.h, setting enable_tkwin to no I cannot help you with these problems because Debian autoconf falls back to autoconf 2.13 if 2.51 (in my case) does not work. This means I cannot reproduce these problems, except to tell you they probably have something to do with either some incompatibility between our configure.ac and sysloc.in and autoconf 2.5x or a real bug in autoconf 2.5x. I am sorry I cannot be more help with this. > c) (OLD PROBLEM) This is wrong, since I do have libvga: > > checking for libvga... no > warning: can't find libvga, setting enable_linuxvga to no I don't have the vga libraries on my system so I don't exercise this logic to see whether this might work under Debian. But let's ignore it for now. I believe linuxvga is not release critical. If you agree and we run out of time before the release, I will just turn it off by default for the release. > > > d) (NEW PROBLEM) Problem finding vfork.h: > > checking vfork.h usability... no > checking vfork.h presence... no > checking for vfork.h... no I confirm this. But two lines below there is the line "checking for vfork... yes" Do you have that as well? Now compare that with what the old configuration system says checking for vfork.h... no checking for working vfork... yes So it looks like the result is the same (at least on my system). I also checked the entire Debian distribution using their search engine for file names, and vfork.h does not exist for any Debian package. So I am wondering if vfork.h has now been superseded (at least on Linux)? > > e) (NEW PROBLEM) It doesn't find my KAI C++ compiler: > > CXX: g++ > > My code to do this was previously in cf/sysconf.in, which doesn't appear to > be used any more. Explanation? Just curious, I should be able to suck > in that code by trial and error. I took virtually all of cf/sysloc.in for the toplevel directory version, but I didn't look at sysconf.in at all since everything seemed to be working fine for me. But by all means stick whatever you need in configure.ac. > > > 3. The build. > > a) Went mostly well but it sure is busy! I previously had code to > eliminate redundant -I options but unfortunately that's not there any more, > making the build a lot less clean looking (i.e. harder to see what's going > on). > > E.g. in this case the compile has 1 redundant -I../../include and 2 redundant > -I/home/mjl/tools/include. I get that as well. Probably a bug report should be sent to libtool about this. I am going to invoke Irwin's rule here. He who remarks on the bug first, gets to file the bug report....;-) I am sure this rule is going to come back to haunt me....;-) > b) Problem building libplplottcltk: I attribute this (see previous post) to a screwup somewhere that puts a blank as the first character in the -L path. Hopefully, you have found the source of the trouble by now. > c) What's the deal with all the weird suffices? > .lo > .la > .lai When libtool links everything together it uses files with these suffixes to keep track of all the information it needs to perform the link properly for both the build area and the install area on any Unix/linux system. .la files have library information in ascii form for the uninstalled version .lai has the same information for the installed version. (diff between the two to see the differences, and look at one form or the other to see all the information that is kept track of) .lo files are the same as .o files except they have been compiled with appropriate flags (-fPIC in the Linux case) to be put into shared objects. The .o files are used to link into static libraries. Note, by default libtool builds both static and shared libraries, but if you are going to be using the shared libraries only, you might as well halve your compilation time (and thus not produce any *.o files or link any static libraries) if you use the --disable-static configuration option. BTW, when I did those timing tests, I didn't use this option so both shared and static libraries were installed. But presumably if someone used --disable-static, the make install latency would be signicantly reduced from the figure I gave. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-23 04:20:28
|
Alan W. Irwin writes:
> On Sun, 22 Dec 2002, Maurice LeBrun wrote:
> > albeit with the following
> > messages:
> >
> > ged$ ./bootstrap.sh
> > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> > WARNING: and `config.h.top', to define templates for `config.h.in'
> > WARNING: is deprecated and discouraged.
> >
> > WARNING: Using the third argument of `AC_DEFINE' and
> > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
> > WARNING: `acconfig.h':
> >
> > WARNING: AC_DEFINE([NEED_MAIN], 1,
> > WARNING: [Define if a function `main' is needed.])
> >
> > WARNING: More sophisticated templates can also be produced, see the
> > WARNING: documentation.
>
> I also get those same messages which appear to be harmless, but I hope somebody
> knows how to get rid of them at some stage.
They're not harmless! Indicators of a real problem, which I am fixing, *and*
which should fix the -dev tk problem if I am right. Hint: take a look at
the defn's of TCL_DIR and such in include/plConfig.h.
> I also get a few more messages tacked on the end:
>
> configure.ac:708: warning: do not use m4_patsubst: use patsubst or
> m4_bpatsubst
> configure.ac:890: warning: do not use m4_regexp: use regexp or m4_bregexp
> autoheader2.50: include/plConfig.h.in' is unchanged
Not sure about these, but after my commit let me know if they're still there.
> > d) (NEW PROBLEM) Problem finding vfork.h:
> >
> > checking vfork.h usability... no
> > checking vfork.h presence... no
> > checking for vfork.h... no
>
> I confirm this. But two lines below there is the line
> "checking for vfork... yes"
>
> Do you have that as well?
>
> Now compare that with what the old configuration system says
>
> checking for vfork.h... no
> checking for working vfork... yes
>
> So it looks like the result is the same (at least on my system).
>
> I also checked the entire Debian distribution using their search engine for
> file names, and vfork.h does not exist for any Debian package. So I am
> wondering if vfork.h has now been superseded (at least on Linux)?
OK, I don't find a vfork.h on my system either, so maybe the old test was just
broken... sheesh.
> > 3. The build.
> >
> > a) Went mostly well but it sure is busy! I previously had code to
> > eliminate redundant -I options but unfortunately that's not there any more,
> > making the build a lot less clean looking (i.e. harder to see what's going
> > on).
> >
> > E.g. in this case the compile has 1 redundant -I../../include and 2 redundant
> > -I/home/mjl/tools/include.
>
> I get that as well. Probably a bug report should be sent to libtool about
> this. I am going to invoke Irwin's rule here. He who remarks on the bug
> first, gets to file the bug report....;-) I am sure this rule is going to
> come back to haunt me....;-)
In this case I guess it's actually AM that's at fault, or at least not doing
it better.
ged$ cd bindings/tcl/
ged$ grep -e -I Makefile
...
AM_CPPFLAGS = -I${top_srcdir}/libltdl -I/home/mjl/tools/include -I/home/mjl/tools/include -I/home/mjl/tools/include
This is the culprit. It'd be nice if it were filtered to get rid of the extra
ones. Oh well, at least it works.
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2002-12-23 05:33:22
|
On Sun, 22 Dec 2002, Maurice LeBrun wrote:
> AM_CPPFLAGS = -I${top_srcdir}/libltdl -I/home/mjl/tools/include -I/home/mjl/tools/include -I/home/mjl/tools/include
>
> This is the culprit. It'd be nice if it were filtered to get rid of the extra
> ones. Oh well, at least it works.
We have complete control of this. That line ultimately comes directly from
the Makefile.am file
AM_CPPFLAGS = @INCLTDL@ @TCLINCCMD@ @ITCLINCCMD@ @TKINCCMD@
where each of those symbols is determined in configure.ac. You might recall
an early post from my AM branch days discussing this "design" decision. It
is a butt-ugly method, but as you say it works. If you can figure out
something more elegant that also works, please go for it by all means. I
believe these symbols appear singly in certain Makefile.am files so they
have to be preserved individually, but certainly the particular combination
of @TCLINCCMD@ @ITCLINCCMD@ @TKINCCMD@ could be cleaned up by defining
another symbol that gets rid of any redundancy that might be in the
combination.
Alan
email: ir...@be...
phone: 250-727-2902 FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________
Linux-powered astrophysics
__________________________
|
|
From: Maurice L. <mj...@ga...> - 2002-12-23 04:41:13
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > On Sun, 22 Dec 2002, Maurice LeBrun wrote: > > > albeit with the following > > > messages: > > > > > > ged$ ./bootstrap.sh > > > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > > > WARNING: and `config.h.top', to define templates for `config.h.in' > > > WARNING: is deprecated and discouraged. > > > > > > WARNING: Using the third argument of `AC_DEFINE' and > > > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > > > WARNING: `acconfig.h': > > > > > > WARNING: AC_DEFINE([NEED_MAIN], 1, > > > WARNING: [Define if a function `main' is needed.]) > > > > > > WARNING: More sophisticated templates can also be produced, see the > > > WARNING: documentation. > > > > I also get those same messages which appear to be harmless, but I hope somebody > > knows how to get rid of them at some stage. > > They're not harmless! Indicators of a real problem, Hmmph. Well, no, this isn't quite right. It's true I was able to make one set of these go away by fixing a very real problem, but another set popped up. Bit of complex machinery here I'm afraid. But I *do* know how to make these (harmless warnings) go away, in theory. Just need to use that third argument. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-23 05:49:25
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Alan W. Irwin writes: > > > On Sun, 22 Dec 2002, Maurice LeBrun wrote: > > > > albeit with the following > > > > messages: > > > > > > > > ged$ ./bootstrap.sh > > > > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > > > > WARNING: and `config.h.top', to define templates for `config.h.in' > > > > WARNING: is deprecated and discouraged. > > > > > > > > WARNING: Using the third argument of `AC_DEFINE' and > > > > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > > > > WARNING: `acconfig.h': > > > > > > > > WARNING: AC_DEFINE([NEED_MAIN], 1, > > > > WARNING: [Define if a function `main' is needed.]) > > > > > > > > WARNING: More sophisticated templates can also be produced, see the > > > > WARNING: documentation. [...] > But I *do* know how to make these (harmless warnings) go away, in theory. > Just need to use that third argument. After initially thinking, sure, why not do it their way, my second reaction is: stop telling me what to do! I'm perfectly happy with the current way we do it; with our AC_DEFINE's scattered far and wide in the configure script it's kinda nice having them nicely organized in acconfig.h (was plConfig.h.in). I dunno, maybe I'll look at the docs, but then again maybe I'll switch to modified versions of AC_DEFINE* that shut up this irritating message. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-23 06:46:17
|
Maurice LeBrun writes:
> Maurice LeBrun writes:
> > Maurice LeBrun writes:
> > > Alan W. Irwin writes:
> > > > On Sun, 22 Dec 2002, Maurice LeBrun wrote:
> > > > > albeit with the following
> > > > > messages:
> > > > >
> > > > > ged$ ./bootstrap.sh
> > > > > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> > > > > WARNING: and `config.h.top', to define templates for `config.h.in'
> > > > > WARNING: is deprecated and discouraged.
> > > > >
> > > > > WARNING: Using the third argument of `AC_DEFINE' and
> > > > > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
> > > > > WARNING: `acconfig.h':
> > > > >
> > > > > WARNING: AC_DEFINE([NEED_MAIN], 1,
> > > > > WARNING: [Define if a function `main' is needed.])
> > > > >
> > > > > WARNING: More sophisticated templates can also be produced, see the
> > > > > WARNING: documentation.
>
> [...]
>
> > But I *do* know how to make these (harmless warnings) go away, in theory.
> > Just need to use that third argument.
>
> After initially thinking, sure, why not do it their way, my second reaction
> is: stop telling me what to do! I'm perfectly happy with the current way we
> do it; with our AC_DEFINE's scattered far and wide in the configure script
> it's kinda nice having them nicely organized in acconfig.h (was
> plConfig.h.in). I dunno, maybe I'll look at the docs, but then again maybe
> I'll switch to modified versions of AC_DEFINE* that shut up this irritating
> message.
Grr... it's in autoheader:
| # Preach.
| my $config_h_top = find_file ("config.h.top?",
| reverse (@prepend_include), @include);
| my $config_h_bot = find_file ("config.h.bot?",
| reverse (@prepend_include), @include);
| my $acconfig_h = find_file ("acconfig.h?",
| reverse (@prepend_include), @include);
| if ($config_h_top || $config_h_bot || $acconfig_h)
^ here need to add "$IF_I_FEEL_LIKE_BEING_PREACHED_TO &&"
| {
| my $msg = << "END";
| Using auxiliary files such as \`acconfig.h\', \`config.h.bot\'
| and \`config.h.top\', to define templates for \`config.h.in\'
| is deprecated and discouraged.
|
| Using the third argument of \`AC_DEFINE\' and
| \`AC_DEFINE_UNQUOTED\' allows to define a template without
| \`acconfig.h\':
|
| AC_DEFINE([NEED_MAIN], 1,
| [Define if a function \`main\' is needed.])
|
| More sophisticated templates can also be produced, see the
| documentation.
| END
| $msg =~ s/^ /WARNING: /gm;
| print STDERR $msg;
| }
Grr...
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X