plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] done for now

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

On Mon, 23 Dec 2002, Maurice LeBrun wrote:

> OK, I've completed my first shakedown of the new plplot config under Linux and
> am basically happy with what I see.

Great!  Thanks for taking it on a test drive.

> Still a few niggling points, hopefully
> minor.  I'll give it a try on Solaris and broader testing on Linux in a few
> days, and hopefully by then my network connection to Japan will be back up so
> I can test under OSF1 and IRIX.

Probably Solaris is the important one for the release, but if you can get to
OSF1 and IRIX as well that would be a nice bonus.

>
> BTW it's easy enough to get rid of that irritating message from autoheader by
> just editing autoheader and chopping it out.  I think I may just have to make
> that my first new FAQ entry in 7 years!

That surgery on autoheader may not be required.

The autoheader script is part of the autoconf package.  From info autoconf
and then searching for autoheader options there is a --warn=no-obsolete
option.  Can you get that autoheader option to work with your version (2.57)
of autoconf? If so, use that option for the autoheader invocation in
bootstrap.sh, and it solves the problem.

For my Debian version 2.53 of autoconf, the autoheader warn options do not
work, but when I put in a bug report about this (yep, I decided to invoke
Irwin's rule...;-)), the Debian packager responded immediately and said to
use the Debian unstable version (2.57) of autoconf where the problem was
solved in the associated autoheader script.  I haven't had a chance to test
that, but it sounds like --warn=no-obsolete should work for you (unless
it only works for the Debian patched version).

Let me know either way so I can make the decision to upgrade to Debian
version 2.57 or not. Note, if you commit the change into bootstrap.sh, every
CVS developer who does not upgrade to 2.57 will encounter an error with that
--warn=no-obsolete option, but I think that is okay since apparently
autoconf 2.57 (and the other combination of stable versions that you found
for the autotools) are readily available.

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
__________________________

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/octave)

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

On Mon, 23 Dec 2002, Joao Cardoso wrote:

> Update of /cvsroot/plplot/plplot/bindings/octave
> In directory sc8-pr-cvs1:/tmp/cvs-serv5660/bindings/octave
>
> Modified Files:
> 	Makefile.am
> Log Message:
> Add both the build and install tree library locations to LD_RUN_PATH.
> Split building of plplot_octave.oct into a compile and a link step, to easy relinking only at install time (when it gets implemented, as an "install" target is the wrong way of doing it under automake).
>

I thought we had agreed to put off anything like this until after the release.

But since you have done this, I have had a look at your implementation, and
I think it needs some more thought. Since you have given two absolute
locations to LD_RUN_PATH with the build location first, this means the
user's installed version will act differently depending on what experimental
stuff he is trying in the build area.  Not good. If the first path were a
relative address (without the `pwd`) it would be safer (unless you chose an
unlucky prefix).  However, then it is not very useful if you want to move
around various places to check out octave examples without doing a full
install.

To cleanly avoid all these version uncertainties (which time and again gave
us trouble for the old configuration solution), I think the best
solution is to specify just one path to LD_RUN_PATH rather than two.  To get
what you want (different linking for the build version and the install
version) simply do a separate link for each version. Of course that means two
separate names, but that can be reconciled with the name octave wants
(plplot_octave.oct) with appropriate symlinks set up in the build directory
as part of each Makefile(.am) rule set to create the build version and the
install version.  You have to create and remove symlinks at just the right
time in the rule set for linking the build version and linking the install
version, but it can be done if you think through the implications of the
symlinks.

On the other hand, if you don't want to deal with these issues now or my
solution also needs refinement, then by all means let us deal with it
post-release, and for the release revert back to what we had before which
was a clean install solution without any possible interference from
subsequent build activities.

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
__________________________

Re: [Plplot-devel] Makefile.examples.in are bogus

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

On Mon, 23 Dec 2002, Maurice LeBrun wrote:

> They all have a hardcoded compiler name.

I am not very aware of cross-platform issues (since the only platforms
accessible to me are Linux and a very limited and peculiarly set up
solaris). For example, that compile-farm solaris environment had gcc so this
hard-coded issue completely passed me by.  Unfortunately, there are probably
more of these hard-coded issues, but the good news is they are easy to fix
once they are spotted.  For example, the CC, CXX, and F77 variables seem to
be available for the present configuration environment so I have used those
variables in the various Makefile.examples.in files.  This solution still
works on Linux, but please test it out to make sure it is what you want.

Alan

[Plplot-devel] Bug in library: Segmentation fault if "Q" hit.

[Joao C. <jc...@fe...>]

Hi,

After all the cvs update, bootstrap, configure, make, make install:

> cd /usr/local/test/lib/plplot5.1.0/examples/c
> make -f Makefile.examples x01c
> gdb ./x01c

If I hit the "Q" key instead of the <ENTER> key, either with the xwin, th=
e tk=20
or the xterm drive, all interactive drivers, I get:

Program received signal SIGSEGV, Segmentation fault.
plexit (errormsg=3D0x4005650c <Address 0x4005650c out of bounds>) at=20
plctrl.c:993
993         if (*errormsg !=3D '\0') {
(gdb) where
#0  plexit (errormsg=3D0x4005650c <Address 0x4005650c out of bounds>)
    at plctrl.c:993
#1  0x400535a5 in ?? ()
#2  0x400530f1 in ?? ()
#3  0x40024284 in plP_eop () at plcore.c:87
#4  0x40026bd5 in c_plend1 () at plcore.c:1306
#5  0x40026b9e in c_plend () at plcore.c:1284
#6  0x08048fd4 in main ()
#7  0x400a04a2 in __libc_start_main () from /lib/libc.so.6

Joao

Re: [Plplot-devel] Re: [Plplot-general] How to Build PLplot to use with Tcl-tk

[Vince D. <vi...@sa...>]

On Mon, 23 Dec 2002, Pankaj Laddha wrote:
> Any clues how to build the Plplot with default drivers on windows with tcl
> bindings.

Get the latest 'cvs HEAD' of plplot from sourceforge (I made some fixes
today), then:

cd plplot/sys/win-tk
nmake -f makefile.vc
nmake -f makefile.vc install

Vince.

[Plplot-devel] Re: [Plplot-general] How to Build PLplot to use with Tcl-tk

[Pankaj L. <pa...@da...>]

Hello Alan,

Thanks for the reply.

I am extremely sorry for all the inconvenience caused due to cross posting of
the message.

I am sure I can figure out how to create "libgd" as mentioned in your message.
But I am not able to use the existing source code of Plplot to make dlls with
default drivers. When I build the dlls and try to load the plplotter package in
tcl, it gives me "could not find procedure Plplotter_Init" error. It seems some
of the source files are missing. I have Plplot 5.1.0 version. Do you have any
idea what is missing?

Any clues how to build the Plplot with default drivers on windows with tcl
bindings.

Regards,
Pankaj.


----- Original Message -----
From: Alan W. Irwin <ir...@be...>
To: Pankaj Laddha <pa...@da...>
Cc: PLplot development list <Plp...@li...>
Sent: Friday, December 20, 2002 10:49 PM
Subject: Re: [Plplot-general] How to Build PLplot to use with Tcl-tk


> Hello Pankaj:
>
> You may not be aware of this, but your cross-posting to both plplot_general
> and plplot_devel is an annoyance to those who are subscribed to both lists
> since we see your posts twice.
>
> My own feeling is you are asking fairly technical questions so your posts
> should go to plplot_devel only.
>
> With regard to the content of your particular message, I would know exactly
> how to answer you in a Linux environment.  You need libgd, libpng, libjpeg,
> and zlib in order to compile the gd.c device driver (which implements the
> png and jpeg devices).
>
> The problem with the Plplot windows environment is it is only supported by
> one guy (Olof Svensson, who is subscribed to plplot_devel, but is not part
> of the core team because of lack of time on his part.) The primary focus of
> plplot core development team is oriented toward the Unix/Linux side, and
> Olof keeps up as well as he can on the windows side in his spare time.  So
> you may have to figure out for yourself how to get the gd device implemented
> in that environment.  The first step would be to create libgd for the
> windows environment.  For instructions on that, see
> http://www.boutell.com/gd/manual2.0.9.html.
>
> If you don't have the time/skills to do that, then there is hope for you in
> about another 6 months or so. The natural way to get access to all the
> Unix/Linux side developments (such as the gd device driver) in windows is to
> use the new configuration scheme to build plplot in a cygwin environment.
> (Cygwin is a free implementation of Unix for windows.) Unfortunately, that
> does not quite work yet because of current incompatibilities between
> autotools and cygwin. We are very close, since everything compiles on Cygwin
> without problems, but there seems to be a linking problem which lots of
> other projects have also encountered. Since both autotools and cygwin are
> developed by the FSF, and people are clamoring for a simple solution, I
> fully expect that situation to be resolved on a fairly short time scale.
> Thus, I am planning to try testing it again in 6 months or so.
>
> 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
> __________________________

[Plplot-devel] done for now

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

OK, I've completed my first shakedown of the new plplot config under Linux and
am basically happy with what I see.  Still a few niggling points, hopefully
minor.  I'll give it a try on Solaris and broader testing on Linux in a few
days, and hopefully by then my network connection to Japan will be back up so
I can test under OSF1 and IRIX.

BTW it's easy enough to get rid of that irritating message from autoheader by
just editing autoheader and chopping it out.  I think I may just have to make
that my first new FAQ entry in 7 years!

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] Makefile.examples.in are bogus

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

They all have a hardcoded compiler name.

c/Makefile.examples.in:
x01c: x01c.c
        plplot_libtool gcc x01c.c $(INCLUDEANDLIB) -o x01c

c++/Makefile.examples.in:
x01cc: x01cc.cc
        plplot_libtool g++ x01cc.cc $(INCLUDEANDLIB) -o x01cc

f77/Makefile.examples.in:
x01f: x01f.f
        plplot_libtool --mode=link g77 x01f.f $(INCLUDEANDLIB) -o x01f

tk/Makefile.examples.in:
xtk01: xtk01.c
        plplot_libtool gcc xtk01.c $(INCLUDEANDLIB) -o xtk01

Without doubt the highest priority thing to fix that I can see.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] COPYING vs COPYING.LIB

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

These files both look identical.  Why do we have both?
-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

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

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)

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot)

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

Alan W. Irwin writes:
 > Thanks very much, Maurice, for tracking down the source of this -dev tk
 > problem.  It's a big load off my mind that this is now fixed.

Cool.  Yeah, me too. :)

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] proper include guards for plConfig.h

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

Although I fixed the include guards in acconfig.h, because of the way
autoheader works they're still broken in include/plConfig.h{,.in}.  Anyone
know of a way to properly handle these?

(i.e. the #endif should be the very last statement to protect against
multiple inclusions)

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot)

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

On Sun, 22 Dec 2002, Maurice LeBrun wrote:

> Update of /cvsroot/plplot/plplot
> In directory sc8-pr-cvs1:/tmp/cvs-serv4775
>
> Modified Files:
> 	configure.ac
> Log Message:
> Fixes to get definitions for CPP (via plConfig.h) correct -- AM_CONFIG_HEADER
> must be called *before* AC_DEFINE's that are to go into the headers.  Solves
> the infamous -dev tk problem.

I confirm this change solves the -dev tk problem, and it also solves all the
interactive tk example problems that I had found before. I have adjusted
ChangeLog and PROBLEMS accordingly.

Also, it had been a while, so I used plplot-test.sh to build all the
non-interactive examples successfully.  So all the usual non-interactive and
interactive tests now pass on Linux again with the new configuration.

Thanks very much, Maurice, for tracking down the source of this -dev tk
problem.  It's a big load off my mind that this is now fixed.

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
__________________________

Re: [Plplot-devel] tcl binding now works on AT branch

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

Alan W. Irwin writes:
 > On Sat, 30 Nov 2002, Maurice LeBrun wrote:
 > 
 > > If the extended search fails PlbasicInit() returns TCL_ERROR, which: (a) is
 > > all the info you really need since you have a stack trace to find where the
 > > error occured
 > 
 > I have seen the stack trace put out by plframe for other errors, and that
 > was most useful, but in the tcl-only situation with no tk driver or plframe
 > is there another way to get at it?  I was floundering around yesterday
 > because I didn't know how to get a stack trace for the tcl-only situation.

Sorry I never got back to you on this one.  Sheesh, have I ever been busy
since you posed it three weeks ago.  Anyway, the simple answer is: "puts
$errorInfo".  See "man n error" for more info.

We could probably improve the Tcl error handling (not to mention many other
areas of Tcl support) in plplot.  I didn't get to do as much with this over
the last year as I wanted but am still hoping..

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

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

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)

[Plplot-devel] Re: Version

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

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
__________________________

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

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

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
__________________________

[Plplot-devel] Re: Version

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

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)

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

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

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)

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)

[Plplot-devel] Version

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

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
__________________________

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
__________________________

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

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

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)

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

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

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)

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

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

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)