plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Aspirin for autoheadache

[Rafael L. <lab...@ps...>]

* 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

Re: [Plplot-devel] Aspirin for autoheadache

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

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
__________________________

Re: [Plplot-devel] Aspirin for autoheadache

[Rafael L. <lab...@ps...>]

* 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

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

[Rafael L. <lab...@ps...>]

* Maurice LeBrun <mj...@ga...> [2003-01-29 22:40]:

> If this works the way you describe, it sounds great.

Hopefully it works the way I described.  If I find some time in the near
future, I will try to implement it.  As a preparation, could you please
indicate which #defines in the current plConfig.h should not be exported
into user's space? You already presented some of them, but I need a complete
list.
 
-- 
Rafael

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

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

Rafael Laboissiere writes:
 > I think that the right approach to this is to create a top-level config.h
 > file (eventually using autoheader) that will contain all the defines that
 > shouldn't appear in the user namespace and remove them from plConfig.h.  In
 > plConfig.h, we add: 
 > 
 >       #if HAVE_CONFIG_H
 >       #  include <config.h>
 >       #endif
 > 
 > Remeber that -DHAVE_CONFIG_H is automatically added by automake to the
 > CFLAGS when the package is built, so the scheme above should work.
 > 
 > Now, when users will compile their applications linked against the PLplot
 > library, the config.h file will not be included, unless they (foolishly and
 > unnecessarily) #define HAVE_CONFIG_H.
 > 
 > In configure.ac, we should use:
 > 
 >     AC_CONFIG_HEADERS([config.h include/plConfig.h include/plDevs.h])
 > 
 > Notice that there is a beneficial side-effect to this: many of the
 > autoheader problems that we were experiencing may be fixed, since autoheader
 > only acts on the first argument of the macro AC_CONFIG_HEADERS.
 > 
 > What do you think?

If this works the way you describe, it sounds great.

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

Re: [Plplot-devel] Aspirin for autoheadache

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

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
__________________________

Re: [Plplot-devel] X problems on SuSe 8.1

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

On Wednesday 29 January 2003 19:17, Alan W. Irwin wrote:
| Joao, can you verify this X problem that was reported to me privately
| for SuSe 8.1?
|
| This problem has popped up before on a few platforms, but I have
| forgotten what we did for a fix.
|
| Alan
=2E..

| ---------- Forwarded message ----------
| Date: Wed, 29 Jan 2003 14:04:43 -0000
| From: Simon Pinches <Sim...@je...>
| To: 'Alan W. Irwin' <ir...@be...>
| Subject: RE: [Plplot-general] Warning: PLplot-5.2.0 has been released
| agai n today
|
| Dear Alan,
|
| Sorry for troubling you again, but....
|
| I re-configured with --enable-dyndrivers and everything now compiled
| okay. However, trying to use the xwin driver gives the following
| error:
|
| Enter device number or keyword: 1
| X Error of failed request:  BadMatch (invalid parameter attributes)
|   Major opcode of failed request:  1 (X_CreateWindow)

This is strange, could it be conflicting  X11 versions? The man page=20
says that everything is OK with the Xcreatewindow call, but some=20
parameters values are not supported...

|   Serial number of failed request:  10
|   Current serial number in output stream:  14
|
| In version 5.1.0 I'd fixed this problem by following Paul Casteels
| advice and adding
|
| #define USE_DEFAULT_VISUAL 1
|
| also for Linux systems rather than just for SunOS in the
| configuration script.  However, in 5.2.0 I notice that this isn't
| even set for SunOS, and setting it in this case didn't help either.
|
| Can you suggest a fix for the new release with SuSE 8.1?

I have no such problems with SuSE-8.1... either at the office or at=20
home...

-Are you using a standard demo, such as x01c?
-Have you installed plplot before running any demo?
-Is any possibility that a conflict with a previouly installed plplot=20
version exists?
-Are you working on a X terminal or in the PC console (under X=20
obviously)?
-How many colors does your X server supports (use xdpyinfo and look for:
    default visual id:  0x21 <------
       visual:
       visual id:    0x21 <-------
       class:    TrueColor
       depth:    16 planes <-----------

I have no more hints for you, but please check the above, as a last=20
resort, and keep us informed.

Thanks,
Joao


|
| Regards,
|
| Simon
|
|
|
| -------------------------------------------------------
| This SF.NET email is sponsored by:
| SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
| http://www.vasoftware.com
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] X problems on SuSe 8.1

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

Joao, can you verify this X problem that was reported to me privately for
SuSe 8.1?

This problem has popped up before on a few platforms, but I have forgotten
what we did for a 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
__________________________

---------- Forwarded message ----------
Date: Wed, 29 Jan 2003 14:04:43 -0000
From: Simon Pinches <Sim...@je...>
To: 'Alan W. Irwin' <ir...@be...>
Subject: RE: [Plplot-general] Warning: PLplot-5.2.0 has been released agai
    n today

Dear Alan,

Sorry for troubling you again, but....

I re-configured with --enable-dyndrivers and everything now compiled okay.
However, trying to use the xwin driver gives the following error:

Enter device number or keyword: 1
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  1 (X_CreateWindow)
  Serial number of failed request:  10
  Current serial number in output stream:  14

In version 5.1.0 I'd fixed this problem by following Paul Casteels advice
and adding

#define USE_DEFAULT_VISUAL 1

also for Linux systems rather than just for SunOS in the configuration
script.  However, in 5.2.0 I notice that this isn't even set for SunOS, and
setting it in this case didn't help either.

Can you suggest a fix for the new release with SuSE 8.1?

Regards,

Simon

Re: [Plplot-devel] Problem in building Shared libraries on Solaris

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

On Wed, 29 Jan 2003, Pankaj Laddha wrote:

> I have verified that we both are using the same version of plplot-5.2.0. I am
> attaching the required files to this mail. From the attached files
> configure : I am using this configure file to configure plplot 5.2.0 package. In
> this files have changed the default options as per my need. I have also changed
> the path of tcl libraries and include folder to reflect my installation of tcl.
> configure.out : It is the output log of "$ ./configure" command.
> make.out :  It is the output log of "$ ./make " command.
>
> I am trying to build plplot-5.2.0 with tcl driver on Solaris platform. I hope
> you can help me to sort the problem.

Thank you for your detailed report.  Two things I noticed.

(1) I am somewhat concerned that you are changing the configure script.  The
more standard way to do what you are trying to do is to set some environment
variables TCLINCDIR, TCLLIBDIR, ITCLINCDIR, ITCLLIBDIR, TKINCDIR, TKLIBDIR
to your locations for the tcl/itcl/tk stuff.  Also, the standard way to turn
off f77, cxx, and python is to specify the --disable-f77 --disable-cxx
--disable-python configure options.

(2) Our static drivers (which for historical reasons are the default) were
not as thoroughly tested as the dynamic drivers before the release.  Because
we have had some bad reports on some platforms for static drivers, we
suggest using the dynamic drivers as a first step.  The way you do that is
to specify the configure option, e.g.,

./configure --enable-dyndrivers --disable-f77 --disable-cxx --disable-python

So lets try one more iteration with an unchanged configure script, the
environment variables set so configure can find the locations of your
tcl/tk/itcl stuff, and the above configure options (you may want a different
install prefix than the default /usr/local as well). Send me the associated
configure.out and make.out off list if you are still having some problems

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
__________________________

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

[Rafael L. <lab...@ps...>]

Thanks, Maurice, for the very clear message stating exactly what the problem
is.

* Maurice LeBrun <mj...@ga...> [2003-01-29 04:34]:

> In summary: 
> 
>  - There should be a clear distinction drawn between these two different
> styles of defines.  One is useful to the user, the other essentially only
> useful internally.
> 
>  - The assumption present in some GNU packages that the existence of the
> HAVE_CONFIG_H define implies the existence of a config.h header is at
> odds with our current configuration.  We should fix this.

I think that the right approach to this is to create a top-level config.h
file (eventually using autoheader) that will contain all the defines that
shouldn't appear in the user namespace and remove them from plConfig.h.  In
plConfig.h, we add: 

      #if HAVE_CONFIG_H
      #  include <config.h>
      #endif

Remeber that -DHAVE_CONFIG_H is automatically added by automake to the
CFLAGS when the package is built, so the scheme above should work.

Now, when users will compile their applications linked against the PLplot
library, the config.h file will not be included, unless they (foolishly and
unnecessarily) #define HAVE_CONFIG_H.

In configure.ac, we should use:

    AC_CONFIG_HEADERS([config.h include/plConfig.h include/plDevs.h])

Notice that there is a beneficial side-effect to this: many of the
autoheader problems that we were experiencing may be fixed, since autoheader
only acts on the first argument of the macro AC_CONFIG_HEADERS.

What do you think?

> I guess this way of handling it among "gnu programs" represents some sort
> of overall plan but I don't like it much.

I do not think that this is an overall plan, but a convinience to only
include build-related definitions at build time.

-- 
Rafael

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

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

Rafael Laboissiere writes:
 > * Maurice LeBrun <mj...@ga...> [2003-01-27 17:29]:
 > 
 > > BTW I just ran into another irritating side effect of the current
 > > configuration system.  Running a recursive search from the top level
 > > shows up HAVE_CONFIG_H defined throughout:
 > > 
 > > ./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H
 > > ...
 > > 
 > > Well the problem occurs when including headers from some gnu tools such as
 > > readline.  In /usr/include/readline/tilde.h --
 > > 
 > > #if defined (HAVE_CONFIG_H)
 > > #  include <config.h>
 > > #endif
 > > 
 > > Whoops.  I guess when this happens we'll just have to #undef HAVE_CONFIG_H
 > > but that seems pretty lame.. is there any way to turn off this define?
 > 
 > I think that there is a logical justification for having this define,
 > provided that we proceed like it is advised in the autoconf documentation.
 > We should replace all instances of `#include "plConfig.h"', by:
 > 
 >      #if HAVE_CONFIG_H
 >      #  include <plConfig.h>
 >      #endif
 >      
 > (cf info -f /usr/share/info/autoconf.info.gz -n "Configuration Headers")
 > 
 > I am making the assumption that all the definitions in plConfig.h are
 > useful only when compiling PLplot itself and are irrelevant for user's
 > applications linked against PLplot.  Is that true?

Well, no, and that's part of the problem.  The other part of the problem is
that certain gnu headers we may want to include assert that #if defined
(HAVE_CONFIG_H) then #  include <config.h> must succeed which in our case
it doesn't of course.  I guess this way of handling it among "gnu programs"
represents some sort of overall plan but I don't like it much.  To me either
you should keep the config details private or export them publically, one
or the other.  Not magically expect a certain header file to be present if
a certain define is made.  That's ok for the system headers, but not in
application space.

We have plConfig.h which gets injected in the user namespace because it *is*
useful.  This is what I was talking about when I complained about our big
problem with all the symbols we probably *shouldn't* be injecting into the
user namespace.

E.g. here's some vanilla autoconf stuff in plConfig.h that probably shouldn't
appear in the user namespace:

    /* Define to 1 if you have the <dlfcn.h> header file. */ 
    #define HAVE_DLFCN_H 1 
     
    /* Define to 1 if you have the `fork' function. */ 
    #define HAVE_FORK 1 
     
    /* Define to 1 if you have the <inttypes.h> header file. */ 
    #define HAVE_INTTYPES_H 1 
     
    /* Define to 1 if you have the <memory.h> header file. */ 
    #define HAVE_MEMORY_H 1 
 
etc, etc.

OTOH, here are some things in plConfig.h that are definitely or may be useful
to the application writer:

    /* If you don't know what this is for, you shouldn't be using it */ 
    /* #undef NOBRAINDEAD */ 
     
    /* Define if dynamic drivers are enabled.*/ 
    #define ENABLE_DYNDRIVERS 1 
     
    /* Define if drivers database is specified.*/ 
    #define DRIVERS_DB "drivers.db" 
     
    /* Define if [incr Tcl] is available */ 
    #define HAVE_ITCL 1 
     
    /* Define if [incr Tk] is available */ 
    #define HAVE_ITK 1 
     
    /* Define if [freetype] is available */ 
    /* #undef HAVE_FREETYPE */ 
     
    /* Define if you want PLplot's float type to be double */ 
    /* #undef PL_DOUBLE */ 
     
    /* Install directories. */ 
     
    #define LIB_DIR "/home/mjl/tools/lib" 
    #define DATA_DIR "/home/mjl/tools/lib/plplot5.2.0/data" 
    #define BIN_DIR "/home/mjl/tools/bin" 
    #define TCL_DIR "/home/mjl/tools/lib/plplot5.2.0/tcl" 
     
    /* Name of package */ 
    #define PACKAGE "plplot" 
     
    /* Define to the address where bug reports for this package should be sent. */
    
    #define PACKAGE_BUGREPORT "" 
     
    /* Define to the full name of this package. */ 
    #define PACKAGE_NAME "" 
     
    /* Define to the full name and version of this package. */ 
    #define PACKAGE_STRING "" 
     
    /* Define to the one symbol short name of this package. */ 
    #define PACKAGE_TARNAME "" 
     
    /* Define to the version of this package. */ 
    #define PACKAGE_VERSION "" 
     
    /* Version number of package */ 
    #define VERSION "5.2.0" 
 
Some of these reflect facts about the package, others about how it was
configured when installed.

In summary: 

 - There should be a clear distinction drawn between these two different
styles of defines.  One is useful to the user, the other essentially only
useful internally.

 - The assumption present in some GNU packages that the existence of the
HAVE_CONFIG_H define implies the existence of a config.h header is at
odds with our current configuration.  We should fix this.

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

Re: [Plplot-devel] Problem in building Shared libraries on Solaris

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

Thanks Alan.

I have verified that we both are using the same version of plplot-5.2.0. I am
attaching the required files to this mail. From the attached files
configure : I am using this configure file to configure plplot 5.2.0 package. In
this files have changed the default options as per my need. I have also changed
the path of tcl libraries and include folder to reflect my installation of tcl.
configure.out : It is the output log of "$ ./configure" command.
make.out :  It is the output log of "$ ./make " command.

I am trying to build plplot-5.2.0 with tcl driver on Solaris platform. I hope
you can help me to sort the problem.

Thanks for your time.

Regards,
Pankaj.

> On Wed, 29 Jan 2003, Pankaj Laddha wrote:
>
> > Can anybody help me to resolved the above errors?
>
> I will try to help but need the complete story.  Here is what I would like
> you to do:
>
> (1) download the latest tarball just to be sure we are on exactly the same
> page.
>
> (2) Make sure every bit is correct.
>
> cksum plplot-5.2.0.tar.gz
> 2721988623 4435633 plplot-5.2.0.tar.gz
>
> (3) Unpack it.
>
> (4) Configure and build it capturing all the relevant output.
>
> cd plplot-5.2.0
> ./configure --whatever-options  >& configure.out
> ./make >& make.out
>
> (5) Send me configure.out and make.out as e-mail attachments.
>
> Once I have those attachments, I may be able to help with the problem that
> you have encountered.
>
> Alan

Re: [Plplot-devel] troubles building plplot 5.2.0 without dynamic drivers

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

On Tuesday 28 January 2003 23:59, Doug Hunt wrote:
> Hi all:  I have been using plplot 5.1 for some time.  I just downloaded
>
> 5.2.0 and ran into this:
>  > ./configure --with-double --prefix=3D/ops/tools
>  > make
>
> ...
>
> gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../bindings/tcl
> -I../bindings/tk -I../bindings//tk-x-plat -I/usr/X11R6/include -g -O2
> -MT matrixInit.lo -MD -MP -MF .deps/matrixInit.Tpo -c
> ../bindings/tcl/matrixInit.c -o matrixInit.o >/dev/null 2>&1
> mv -f .libs/matrixInit.lo matrixInit.lo
> make[1]: *** No rule to make target `dg300d.lo', needed by
> `libplplotdrv.la'.  Stop.
> make[1]: Leaving directory `/home/huntd/src/plplot-5.2.0/drivers'
> make: *** [all-recursive] Error 1

Hi, Doug

I confirm your report on my SuSE-8.1.

We are changing our configuration stuff, using autotools/libtool, hopping=
 to=20
reach a more broad range of platforms, and it looks like there are still =
some=20
problems left.

I have tested the current release in a variety of platforms, RH-8.0, SuSE=
-8.1=20
and OSF1 and other developers in Debian-?, RH-7.2 and other platforms, bu=
t it=20
looks like that we didn't test all possibilities.

So I advise you (and others) to configure using --enable-dyndrivers. In t=
he=20
above systems that I tested I always used "--enable-dyndrivers=20
--disable-static". I always use the disable-static  to save compile time =
and=20
disk space, but that depends on your platform.

I have just now configured and make plplot-5.2.0 with=20

    ./configure --with-double --prefix=3D/usr/local/test/  \
        --enable-dyndrivers

and it succeeded in my SuSE-8.1 system.

In case your *make* (not configure) fails with the last few lines saying:

Making all in include
make[1]: Entering directory `/home/jcard/tmp/plplot-5.2.0/include'
cd .. && /bin/sh /home/jcard/tmp/plplot-5.2.0/missing --run autoheader
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
(... other warnings)

please type the command:

     touch include/plDevs.h.in

and restart the make (this has just happened to me after the first=20
configure/make fails and I issued the second configure/make).

Thanks for reporting this and other problems that you might find, it is t=
hanks=20
to detailed  reports, including the platform and configure command used, =
that=20
we can manage to solve problems and improve PLplot.

>
> Also, I have developed a driver under 5.1, but I can't seem to figure
> out how to get it to work under 5.2.  I keep running into GNU
> automake/autoconf/aclocal errors.
> I gather the old process of modifying cf/configure.in and running
> autoconf no longer works.

Yes, you are right. The best advise I can give to you is to look how othe=
r=20
drivers are currently configured. Don't look at the cf directory, it is s=
till=20
there because historical reasons :), look at the *.in files in both the t=
op=20
and drivers directory.

Joao

> Is there any doc for how to do this under 5.2?  The instructions in
> drivers/README.drivers seems out of date.
>
> Any ideas on these problems?
>
> Thanks much!
>
>   Doug Hunt
>
> P.S:
>
> $ uname -a
> Linux pegasus.cosmic.ucar.edu 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
> i686 unknown
> $ cat /etc/redhat-release
> Red Hat Linux release 7.2 (Enigma)
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] troubles building plplot 5.2.0 without dynamic drivers

[Doug H. <dh...@uc...>]

Hi all:  I have been using plplot 5.1 for some time.  I just downloaded 
5.2.0 and ran into this:

 > ./configure --with-double --prefix=/ops/tools
 > make

...

gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../bindings/tcl 
-I../bindings/tk -I../bindings//tk-x-plat -I/usr/X11R6/include -g -O2 
-MT matrixInit.lo -MD -MP -MF .deps/matrixInit.Tpo -c 
../bindings/tcl/matrixInit.c -o matrixInit.o >/dev/null 2>&1
mv -f .libs/matrixInit.lo matrixInit.lo
make[1]: *** No rule to make target `dg300d.lo', needed by 
`libplplotdrv.la'.  Stop.
make[1]: Leaving directory `/home/huntd/src/plplot-5.2.0/drivers'
make: *** [all-recursive] Error 1

Also, I have developed a driver under 5.1, but I can't seem to figure 
out how to get it to work under 5.2.  I keep running into GNU 
automake/autoconf/aclocal errors.
I gather the old process of modifying cf/configure.in and running 
autoconf no longer works.
Is there any doc for how to do this under 5.2?  The instructions in 
drivers/README.drivers seems out of date.

Any ideas on these problems?

Thanks much!

  Doug Hunt

P.S:

$ uname -a
Linux pegasus.cosmic.ucar.edu 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 
i686 unknown
$ cat /etc/redhat-release
Red Hat Linux release 7.2 (Enigma)

Re: [Plplot-devel] Problem in building Shared libraries on Solaris

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

On Tuesday 28 January 2003 18:39, Pankaj Laddha wrote:
> Hi Alan,

Hi Pankaj

>
> I tried building the Plplot 5.2.0 with tcl drivers. I am getting follow=
ing
> errors.
>
> Undefined                       first referenced
>  symbol                             in file
> XClearWindow                      =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XSync                             =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XFlush                            =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XLookupString                     =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XWarpPointer                      =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XParseColor                       =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XQueryPointer                     =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> XDrawLines                        =20
> ../drivers/.libs/libplplotdrv.al(plframe.lo) (symbol belongs to implici=
t
> dependency /usr/lib/libX11.so.4)
> ld: fatal: Symbol referencing errors. No output written to
> .libs/libplplot.so.5.2.0
> make[1]: *** [libplplot.la] Error 1
> make[1]: Leaving directory `/usr/pankaj/plplot/plplot-5.2.0/src'
> make: *** [all-recursive] Error 1
>
> Also, I have enabled following options,
> with_shlib: yes      with_double: no
> with_debug: no     with_opt: yes
> with_warn: no       with_profile: no
> with_gcc: no         with_rpath: yes
> with_freetype: no
>
> enable_xwin: no      enable_tcl: yes

Try building with the xwin driver. The missing symbols from plframe, need=
ed to=20
build the tk driver, are in the X11 libraries. And anyway the tk driver n=
eeds=20
the xwin driver.

I suspect that you are building with static libraries and without dynamic=
=20
drivers. Can you please send us the configure command that you used? In c=
ase=20
you don't remember it, see the contents of the file config.summary.

You can also try to disable building static libraries and enable dynamic=20
drivers. One step a time:

=2E/configure --enable-dyndrivers --disable-static"
what happens? If it does not works, try

"./configure --enable-dyndrivers"
what happens?  If it does not works, try

"./configure --disable-static" what happens?

Joao

> enable_tk: yes         enable_itcl: no
> enable_cxx: no        enable_python: no
> enable_f77: no        enable_java: no
> enable_octave: no   enable_gnome: no
> enable_tkwin: no
>
> Can anybody help me to resolved the above errors?
>
> Thanks,
> Pankaj.
>
>
>
>
>
> ----- Original Message -----
> From: Alan W. Irwin <ir...@be...>
> To: Pankaj Laddha <pa...@da...>
> Cc: PLplot development list <Plp...@li...>
> Sent: Thursday, January 23, 2003 12:43 PM
> Subject: Re: [Plplot-devel] Problem in building Shared libraries on Sol=
aris
>
> > On Thu, 23 Jan 2003, Pankaj Laddha wrote:
> > > Hi All,
> > >
> > > I am using plplot version 5.1.0. I am trying to build shared librar=
ies
> > > on Solaris. I want shared library with tcl/tk support. When I
> > > give --enable-tcl, --with-shlib options to "configure", I am gettin=
g
> > >
> > > "Checking how to build shared libraries...: Unknown"
> > >
> > > message. Also, in the output log of "configure" I observe
> > > "enable_tcl=3DNo".
> > >
> > > Can anybody help me to resolve these problems?
> > >
> > > Thanks for any help.
> >
> > I cannot help you with 5.1.0, but you might want to try the recently
> > released PLplot 5.2.0.  (See the recent announcement on plplot-genera=
l.)
> > Shared libraries worked fine with PLplot-5.2.0 for the minimal Solari=
s
> > system (without tcl/tk) that I had at my disposal for testing.  I wou=
ld
> > be most interested in your report (positive or negative) about whethe=
r
> > you can get PLplot 5.2.0 to work with tcl/tk on Solaris.
> >
> > 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 Modelli=
ng
> > and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotti=
ng
> > software package (plplot.org).
> >
> > __________________________
> >
> > Linux-powered Science
> > __________________________
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem in building Shared libraries on Solaris

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

On Wed, 29 Jan 2003, Pankaj Laddha wrote:

> Can anybody help me to resolved the above errors?

I will try to help but need the complete story.  Here is what I would like
you to do:

(1) download the latest tarball just to be sure we are on exactly the same
page.

(2) Make sure every bit is correct.

cksum plplot-5.2.0.tar.gz
2721988623 4435633 plplot-5.2.0.tar.gz

(3) Unpack it.

(4) Configure and build it capturing all the relevant output.

cd plplot-5.2.0
./configure --whatever-options  >& configure.out
./make >& make.out

(5) Send me configure.out and make.out as e-mail attachments.

Once I have those attachments, I may be able to help with the problem that
you have encountered.

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
__________________________

Re: [Plplot-devel] Problem in building Shared libraries on Solaris

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

Hi Alan,

I tried building the Plplot 5.2.0 with tcl drivers. I am getting following
errors.

Undefined                       first referenced
 symbol                             in file
XClearWindow                        ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XSync                               ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XFlush                              ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XLookupString                       ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XWarpPointer                        ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XParseColor                         ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XQueryPointer                       ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
XDrawLines                          ../drivers/.libs/libplplotdrv.al(plframe.lo)
(symbol belongs to implicit dependency /usr/lib/libX11.so.4)
ld: fatal: Symbol referencing errors. No output written to
.libs/libplplot.so.5.2.0
make[1]: *** [libplplot.la] Error 1
make[1]: Leaving directory `/usr/pankaj/plplot/plplot-5.2.0/src'
make: *** [all-recursive] Error 1

Also, I have enabled following options,
with_shlib: yes      with_double: no
with_debug: no     with_opt: yes
with_warn: no       with_profile: no
with_gcc: no         with_rpath: yes
with_freetype: no

enable_xwin: no      enable_tcl: yes
enable_tk: yes         enable_itcl: no
enable_cxx: no        enable_python: no
enable_f77: no        enable_java: no
enable_octave: no   enable_gnome: no
enable_tkwin: no

Can anybody help me to resolved the above errors?

Thanks,
Pankaj.





----- Original Message -----
From: Alan W. Irwin <ir...@be...>
To: Pankaj Laddha <pa...@da...>
Cc: PLplot development list <Plp...@li...>
Sent: Thursday, January 23, 2003 12:43 PM
Subject: Re: [Plplot-devel] Problem in building Shared libraries on Solaris


> On Thu, 23 Jan 2003, Pankaj Laddha wrote:
>
> > Hi All,
> >
> > I am using plplot version 5.1.0. I am trying to build shared libraries on
> > Solaris. I want shared library with tcl/tk support. When I
> > give --enable-tcl, --with-shlib options to "configure", I am getting
> >
> > "Checking how to build shared libraries...: Unknown"
> >
> > message. Also, in the output log of "configure" I observe "enable_tcl=No".
> >
> > Can anybody help me to resolve these problems?
> >
> > Thanks for any help.
>
> I cannot help you with 5.1.0, but you might want to try the recently
> released PLplot 5.2.0.  (See the recent announcement on plplot-general.)
> Shared libraries worked fine with PLplot-5.2.0 for the minimal Solaris
> system (without tcl/tk) that I had at my disposal for testing.  I would be
> most interested in your report (positive or negative) about whether you can
> get PLplot 5.2.0 to work with tcl/tk on Solaris.
>
> 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
> __________________________
>
>

Re: [Plplot-devel] Autoheadaches

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

On Tue, 28 Jan 2003, Rafael Laboissiere wrote:

> I have not seen Alan's announcement to the plplot-general mailing list.  It
> seems that my suggestion above came too late.

I wasn't absolutely sure myself on this issue, but once Maurice agreed this
was the right thing to do, I just went ahead.  I think it will be okay.

Alan

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

[Rafael L. <lab...@ps...>]

* Maurice LeBrun <mj...@ga...> [2003-01-27 17:29]:

> BTW I just ran into another irritating side effect of the current
> configuration system.  Running a recursive search from the top level
> shows up HAVE_CONFIG_H defined throughout:
> 
> ./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H
> ./bindings/f77/Makefile:DEFS = -DHAVE_CONFIG_H
> ./bindings/java/Makefile:DEFS = -DHAVE_CONFIG_H
> ...
> 
> Well the problem occurs when including headers from some gnu tools such as
> readline.  In /usr/include/readline/tilde.h --
> 
> #if defined (HAVE_CONFIG_H)
> #  include <config.h>
> #endif
> 
> Whoops.  I guess when this happens we'll just have to #undef HAVE_CONFIG_H
> but that seems pretty lame.. is there any way to turn off this define?

I think that there is a logical justification for having this define,
provided that we proceed like it is advised in the autoconf documentation.
We should replace all instances of `#include "plConfig.h"', by:

     #if HAVE_CONFIG_H
     #  include <plConfig.h>
     #endif
     
(cf info -f /usr/share/info/autoconf.info.gz -n "Configuration Headers")

I am making the assumption that all the definitions in plConfig.h are
useful only when compiling PLplot itself and are irrelevant for user's
applications linked against PLplot.  Is that true?

-- 
Rafael

[Plplot-devel] Aspirin for autoheadache

[Rafael L. <lab...@ps...>]

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

Re: [Plplot-devel] Autoheadaches

[Rafael L. <lab...@ps...>]

[Replying to myself:]

* Rafael Laboissiere <lab...@ps...> [2003-01-28 09:06]:

> I agree that a new interim release has to be done as soon as possible.  I
> would be reluctant though to replace the tarball by another one with the
> same name.  First, I even do not now if this is possible in the SF "Files"
> interface.  Second, giving two different things the same name would only
> lead to confusion.  You might set in it another VERSION string like
> "5.2.0-rev1", or whatever.  On the other hand, just bumping the number to
> 5.2.1 with just a change in a file's date is an overkill.

I have not seen Alan's announcement to the plplot-general mailing list.  It
seems that my suggestion above came too late.
 
-- 
Rafael

[Plplot-devel] Re: Autoheadaches

[Rafael L. <lab...@ps...>]

* Maurice LeBrun <mj...@ga...> [2003-01-27 17:41]:

> BTW I tried this suggestiong but found that AC_CONFIG_HEADERS doesn't solve
> the problem at hand.. I still get:
> 
> Making all in include
> cd .. && /bin/sh /home/mjl/dev/plplot/latest/missing --run autoheader

You are right.  I investigated this issue more deeply and discovered that
Automake always include in include/Makefile.in a rule for rebuilding the
files defined in AC_CONFIG_HEADERS using autoheader.  For now, I did not
discover how to disable this.

Now, if the call to autoheader that you metion above only happens for
developper, that is okay, since it will be harmless.  What is very important
for us right now is to get a source tarball for which autoheader is not
called when users run configure/make.

> This stuff is mostly orthogonal to the stuff I was looking at, which
> included:
>  [...]
>  - separation of internal-use-only configuration info from headers exported
>    to the public namespace
>  - proper include guards for headers
> 
> The latter one does overlap with the plConfig.h / plDevs.h problem tho.

Since you are reluctant to incorporate plDevs.h into plConfig.h (and I
understand your arguments), we must find a way to get the Autotools (in this
case Automake specifically) to behave correctly with two configuration
header files. 

One of the things that is strange now is that all the PLD_* #defines are
duplicated in plConfig.h.in and plDevs.h.in.  That is possibly a screw-up of
mine in the past.

-- 
Rafael

Re: [Plplot-devel] Autoheadaches

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-01-27 15:07]:

> Can you give a reference for the "deprecated".  I have the impression you
> are correct, [...]

Three references:

1) When you run autoheader (from autoconf package version 2.57) on
   configure.ac with AM_CONFIG_HEADER instead of AC_CONFIG_HEADERS, you get
   the error message:

     $ autoheader
     autoheader2.50: error: AC_CONFIG_HEADERS not found in configure.ac
   
2) It is mentioned on one of the files of automake 1.7:
     
     $ fgrep AM_CONFIG_HEADER /usr/share/aclocal-1.7/header.m4
     # AM_CONFIG_HEADER is obsolete.  It has been replaced by AC_CONFIG_HEADERS.

3) In the Automake documentation:

     $ info -f /usr/share/info/automake-1.7.info-1.gz -n Optional

> [...] but when I looked for it last night I got two stories, (from info
> automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional.  I am
> sure I have also seen the story "deprecated", but can you remind me where?
     
Automake-1.7 still implements AM_CONFIG_HEADER for backwards compatibility.

> I think there is a bit of value in that file (isinf, for example).
> Where/how should we do the same thing without that file?

Well, I get here:

    $ fgrep ISINF acconfig.h include/plConfig.h.in
    acconfig.h:#undef HAVE_ISINF
    include/plConfig.h.in:#undef HAVE_ISINF

Actually, acconfig.h is fully contained in include/plConfig.h.in.  This is
why I think it is useless (just run diff -u acconfig.h include/plConfig.h.in
to convince yourself).

> A lot of this "dog's breakfast" is my fault. I don't understand autoconf so
> I left a lot of cruft in without much understanding of what was going on.  I
> was just thankful it worked at all.

It is also partly my fault, since I have let you play the Sorcerer's
Apprentice without much guidance.  Of course, I foolishly forgot my AM-LT
magic hat in the CVS repository and now the splinters of the broom are
popping out everywhere...

Fairy-tale analogies apart, the Autotools have evolved quite a lot since I
started the AM-LT branch in the PLplot repository.  I am quite sure that are
other obsolete constructs remaining in many places.

> Meanwhile, I need some input from Maurice and/or Geoffrey on what to do
> with the "touch" workaround. It seems that does work for Joao so I expect
> my tests (and Maurice's tests) of it tonight will also confirm that.
> Assuming that, should I overwrite the plplot-5.2.0 tarball and source rpm
> with the changed date on include/plDevs.h.in?  Remember, those files are
> going to get downloaded a lot before we can bring out 5.2.1.  Of course I
> will be informing plplot-general of the status of the SF file release (if I
> update those SF files) as well as the workaround.

I agree that a new interim release has to be done as soon as possible.  I
would be reluctant though to replace the tarball by another one with the
same name.  First, I even do not now if this is possible in the SF "Files"
interface.  Second, giving two different things the same name would only
lead to confusion.  You might set in it another VERSION string like
"5.2.0-rev1", or whatever.  On the other hand, just bumping the number to
5.2.1 with just a change in a file's date is an overkill.

-- 
Rafael

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

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

Alan W. Irwin writes:
 > On Mon, 27 Jan 2003, Rafael Laboissiere wrote:
 > 
 > > I have plunged more deeply into the header configuration problem.  I seems
 > > that that are several small independent problems and the conjunction of some
 > > of them may have been triggering the bug observed by Joao.  Let us see which
 > > are those problems:
 > >
 > > 1) AC_CONFIG_HEADERS should be used in place of AM_CONFIG_HEADER in
 > >    configure.ac.  I guess that the use of the deprecated AM_CONFIG_HEADER is
 > >    harmful with the present version of autoconf/automake, but who nows.
 > 
 > Can you give a reference for the "deprecated".  I have the impression you
 > are correct, but when I looked for it last night I got two stories, (from
 > info automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional.  I
 > am sure I have also seen the story "deprecated", but can you remind me where?

BTW I tried this suggestiong but found that AC_CONFIG_HEADERS doesn't solve
the problem at hand.. I still get:

Making all in include
cd .. && /bin/sh /home/mjl/dev/plplot/latest/missing --run autoheader

 > Maurice, do you concur with these suggested steps?  

I think there are still a lot of outstanding issues.

 > Before Christmas, I
 > believe you had a whole shopping list of autoconf-related changes you wanted
 > to do.  Does this work fall in line with that shopping list?  I don't want
 > to work against what you wanted to do, but on the other hand, I would like
 > to bring out 5.2.1 fairly soon (this weekend or next depending on how hard
 > it is to implement/test Rafael's suggestions, and how much help I have for
 > doing that).

This stuff is mostly orthogonal to the stuff I was looking at, which included:
 - support for --with-warn,  --with-profile, etc
 - better support for non-GNU compilers (e.g. KCC)
 - separation of internal-use-only configuration info from headers exported to
   the public namespace
 - proper include guards for headers

The latter one does overlap with the plConfig.h / plDevs.h problem tho.

I really have no idea when I'm going to be able to work on any of that, as I
have features work to do and can hack my way around the config issues for now.

 > Meanwhile, I need some input from Maurice and/or Geoffrey on what to do with
 > the "touch" workaround. It seems that does work for Joao so I expect my
 > tests (and Maurice's tests) of it tonight will also confirm that.  Assuming
 > that, should I overwrite the plplot-5.2.0 tarball and source rpm with the
 > changed date on include/plDevs.h.in?  

Yes.

 > Remember, those files are going to get
 > downloaded a lot before we can bring out 5.2.1.  Of course I will be
 > informing plplot-general of the status of the SF file release (if I update
 > those SF files) as well as the workaround.

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

Re: [Plplot-devel] Autoheadaches [was: Re: Make of plplot-5.2.0 fails ...]

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

Rafael Laboissiere writes:
 > 2) The file include/plDevs.h is totally useless since all of its definitions
 >    are already duplicated in include/plConfig.h.  I would recommend to
 >    delete taht file from the repository (or actually include/plDevs.h.in)
 >    and replace all inclusions of plDevs.h by plConfig.h.  The files
 >    concerned by this change are drivers/*.c,
 >    bindings/tk/{plserver.h,tcpip.c}, include/plcore.h, and src/plfreetype.c.
 >    Also, remove include/plDevs.h from the call to AC_CONFIG_HEADERS in
 >    configure.ac and from the list pkginclude_HEADERS in include/Makefile.am.

I would prefer to see the device stuff vanish from plConfig.h instead.
Certainly this new, "powerful" configuration system can handle more
than one generated header file!

BTW I just ran into another irritating side effect of the current
configuration system.  Running a recursive search from the top level
shows up HAVE_CONFIG_H defined throughout:

./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H
./bindings/f77/Makefile:DEFS = -DHAVE_CONFIG_H
./bindings/java/Makefile:DEFS = -DHAVE_CONFIG_H
...

Well the problem occurs when including headers from some gnu tools such as
readline.  In /usr/include/readline/tilde.h --

#if defined (HAVE_CONFIG_H)
#  include <config.h>
#endif

Whoops.  I guess when this happens we'll just have to #undef HAVE_CONFIG_H but
that seems pretty lame.. is there any way to turn off this define?  I grepped
for all the packages on my RH 7.3 system that do this and came up with the
following list:

/usr/include/kde/ksslcertificate.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/ksslpkcs12.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/ksslutils.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/decoder/cddaPlugin.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/decoder/vorbisPlugin.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/frame/audioFrame.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/frame/rawFrame.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/input/cddaInputStream.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/oggvorbis/vorbisDecoder.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/oggvorbis/oggFrame.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/oggvorbis/ovFramer.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/oggvorbis/vorbisInfo.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/mpeglib/util/abstract/abs_thread.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/ksslpemcallback.h:#ifdef HAVE_CONFIG_H
/usr/include/kde/ksslpkcs7.h:#ifdef HAVE_CONFIG_H
/usr/include/gkrellm/gkrellm.h:#ifdef HAVE_CONFIG_H
/usr/include/readline/chardefs.h:#if defined (HAVE_CONFIG_H)
/usr/include/readline/chardefs.h:#endif /* !HAVE_CONFIG_H */
/usr/include/readline/tilde.h:#if defined (HAVE_CONFIG_H)

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