Re: [Plplot-devel] plplot_AT under Linux RH 7.3

[Maurice L. <mj...@ga...>]

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)