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

[Alan W. I. <ir...@be...>]

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
__________________________