gnuplot-beta

Build problem

[Juergen W. <wie...@fr...>]

Hi,

./prepare gives me the following error message:

============================================================================
configure.in:243: error: possibly undefined macro: AC_MSG_WARN
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Some part of the preparation process failed.
Please refer to INSTALL for details.
============================================================================

I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
versions available.  This happens with a freshly checked out local
copy.  Are there any other autotools which need to be up to date?

If I use a .tar.gz from another computer (make dist) on the same
platform, ./configure and make && make install work fine.


Juergen

Re: Build problem

[<br...@ph...>]

Juergen Wieferink wrote:
> Hi,
> 
> ./prepare gives me the following error message:
> 
> ============================================================================
> configure.in:243: error: possibly undefined macro: AC_MSG_WARN
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> 
> Some part of the preparation process failed.
> Please refer to INSTALL for details.
> ============================================================================

I don't see that happening here (same versions you used, on Cygwin, with 
freshly cvs-updated sources).  There are some Warnings, but they all 
only concern warnings from Cygwin-installed stuff in /usr/share/aclocal.

This is in a tree that has been built in before, though.  But since the 
problem is in configure.in processing by autoconf, which is done 
unconditionally by 'prepare', that shouldn't make a difference.

> I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
> versions available.  This happens with a freshly checked out local
> copy.  Are there any other autotools which need to be up to date?

I don't think so.

> If I use a .tar.gz from another computer (make dist) on the same
> platform, ./configure and make && make install work fine.

No surprise --- they have nothing to with autoconf failing on configure.in.

Re: Build problem

[James R. V. Z. <jr...@co...>]

Juergen Wieferink <wie...@fr...> wrote:

>  ./prepare gives me the following error message:
>
>  ===========================================================================
>  configure.in:243: error: possibly undefined macro: AC_MSG_WARN
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
..
> I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
> versions available.  

I suggest you check for extra copies of autoconf or automake, which
may be hiding the versions you mention.  E.g.
  
  type -a autoconf
  type -a automake

               - Jim Van Zandt

Re: Build problem

[Juergen W. <wie...@fr...>]

> I suggest you check for extra copies of autoconf or automake, which
> may be hiding the versions you mention.  E.g.
>
>   type -a autoconf
>   type -a automake

Good idea.  But I've checked them using

  autoconf --version
  automake --version

so I should be save.
  
Juergen
  

Re: Build problem

[James R. V. Z. <jr...@co...>]

Juergen Wieferink <wie...@fr...> wrote:
>   > I suggest you check for extra copies of autoconf or automake, which
>   > may be hiding the versions you mention.  E.g.
>   >
>   >   type -a autoconf
>   >   type -a automake
>
>   Good idea.  But I've checked them using
>
>     autoconf --version
>     automake --version
>
>   so I should be save.

That will show you the first versions found in PATH.  But the
configure/build scripts might not respect the PATH.  I think it's
easiest to check for multiple versions directly.  If there are none,
then there is nothing to worry about.  

             - Jim Van Zandt

Re: Build problem

[Hardy G. <nt...@ma...>]

James R. Van Zandt wrote:
:
> That will show you the first versions found in PATH.  But the
> configure/build scripts might not respect the PATH.  I think it's
> easiest to check for multiple versions directly.  If there are none,
> then there is nothing to worry about.  
:

For my installation all different paths does show the same version.

BTW configure is being generated, but (for me) it fails with

checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
./configure: line 13470: syntax error near unexpected token `CAIRO,'
./configure: line 13470: `    PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,'

Any ideas?

Hardy

Re: Build problem

[<tim...@en...>]

Hardy Griech wrote:
> James R. Van Zandt wrote:
> :
>  =20
>> That will show you the first versions found in PATH.  But the
>> configure/build scripts might not respect the PATH.  I think it's
>> easiest to check for multiple versions directly.  If there are none,
>> then there is nothing to worry about. =20
>>    =20
> :
>
> For my installation all different paths does show the same version.
>
> BTW configure is being generated, but (for me) it fails with
>
> checking dependency style of g++... gcc3
> checking how to run the C++ preprocessor... g++ -E
> ./configure: line 13470: syntax error near unexpected token `CAIRO,'
> ./configure: line 13470: `    PKG_CHECK_MODULES(CAIRO, cairo >=3D 0.9.0=
,'
>
> Any ideas?
>
> Hardy
>  =20
Dear Hardy,

This appears because of a problem with pkg-config, or the absence of it.=20
Here is a relevant quote I found with google :

___________
/    When configuring EVAS, why do I see this:/

	checking whether directfb backend is to be built... ./configure: line 92=
43:=20
	   syntax error near unexpected token `PKG_CHECK_MODULES(DIRECTFB,'
	./configure: line 9243: `          PKG_CHECK_MODULES(DIRECTFB, directfb =
>=3D 0.9.16)'

    You don't have pkg-config installed, or setup properly. To correct=20
this, download, build, and install pkg-config=20
<http://www.freedesktop.org/software/pkgconfig/>. If this error still=20
shows up after you install  pkg-config, it is because aclocal isn't=20
finding the pkg.m4 and using it. Make sure that pkg.m4 is in your=20
aclocal share (usually: /usr/local/share/aclocal). If it isn't there,=20
find out whats wrong and get it there. If it is there, re-run=20
./autogen.sh and the new m4 will be used and the problem won't reappear.
___________

But this raises an interesting point : pkg-config is only needed if you=20
want the wxWidgets terminal. So I guess I should add a non-fatal test=20
for pkg-config, and call the PKG_CHECK_MODULES macro only if possible,=20
otherwise disable the wxWidgets termina.

Timoth=E9e

Re: Build problem

[Hardy G. <nt...@ma...>]

Juergen Wieferink wrote:
> ============================================================================
> configure.in:243: error: possibly undefined macro: AC_MSG_WARN

Although this might seem to be outdated, I have the same problem on a 
cygwin installation with the same versions of automake and automake like 
Jürgen.

Has anybody found a solution?

Hardy

Re: Build problem

[<br...@ph...>]

Hardy Griech wrote:
> 
> Although this might seem to be outdated, I have the same problem on a 
> cygwin installation with the same versions of automake and automake like 

I'm sure it works with current autoconf and automake on Cygwin --- if 
that Cygwin contains enough other things.  I have current Cygwin 
versions of just about everything GNU related to development installed 
here (including TeX, auto tools, pkg-config, gd, png, font utils and 
whatnot).

I.e. the only solution needed for Cygwin is "install more of it."

Re: Build problem

[Hardy G. <nt...@ma...>]

Hans-Bernhard Bröker wrote:
> Hardy Griech wrote:
>>
>> Although this might seem to be outdated, I have the same problem on a 
>> cygwin installation with the same versions of automake and automake like 
> 
> I'm sure it works with current autoconf and automake on Cygwin --- if 
> that Cygwin contains enough other things.  I have current Cygwin 
> versions of just about everything GNU related to development installed 
> here (including TeX, auto tools, pkg-config, gd, png, font utils and 
> whatnot).

I hoped so too.  But reality check showed that it does not work... :-(

Ethan Merrit was so kind to send me a configure from a working linux build.

Comparison shows a lot of differences.  Not very astonishing is that 
AC_MSG_WARN in my version has not been expanded.  Interesting is that 
PKG_CHECK_MODULES has not been expanded too.

Unfortunately I'm not an automake/autoconf expert, but perhaps this is a 
problem of some include paths (m4?).

Here is a small snippet of the problem area CAIRO:

<mine>
     PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,
     HAVE_CAIRO=1,     AC_MSG_WARN([Cairo can't be found. The wxWidgets 
terminal will not be compiled
     enable_wxwidgets_ok=no
   )
</mine>

<ethans>
if test $pkg_failed = yes; then
         CAIRO_PKG_ERRORS=`$PKG_CONFIG --errors-to-stdout --print-errors 
"cairo >= 0.9.0"`
         # Put the nasty error message in config.log where it belongs
         echo "$CAIRO_PKG_ERRORS" 1>&5

             { echo "$as_me:$LINENO: WARNING: Cairo can't be found. The 
wxWidgets terminal will not b
echo "$as_me: WARNING: Cairo can't be found. The wxWidgets terminal will 
not be compiled." >&2;}
     enable_wxwidgets_ok=no

elif test $pkg_failed = untried; then
             { echo "$as_me:$LINENO: WARNING: Cairo can't be found. The 
wxWidgets terminal will not b
echo "$as_me: WARNING: Cairo can't be found. The wxWidgets terminal will 
not be compiled." >&2;}
     enable_wxwidgets_ok=no
</ethans>

I have omitted a lot of bunch beforehand which contains something like 
'--exists --print-errors' and so on.  Everybody with a working configure 
can see that.

My conclusion is still that there is something broken in the (my?) 
cygwin installation with automake and so on.  Perhaps you 
(Hans-Bernhard) has set a path to get m4/automake/autoconf working?

Hardy

Re: Build problem

[Hardy G. <nt...@ma...>]

Timothée Lecomte wrote:
:

> This appears because of a problem with pkg-config, or the absence of it. 
> Here is a relevant quote I found with google :

Dear Timothée,

thanks for the hint.  I've installed pkg-config, but the problem still 
remains (BTW "type -a pkg-config" shows "pkg-config is 
/usr/local/bin/pkg-config"):

checking how to run the C++ preprocessor... g++ -E
./configure: line 13465: syntax error near unexpected token `CAIRO,'
./configure: line 13465: `    PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,'

Also the previous prepare shows the problem Jürgen already reported:

configure.in:243: error: possibly undefined macro: AC_MSG_WARN
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.

I start to think, that the autoconf/automake-and-so-on-installation is 
somehow broken in cygwin or gnuplot uses some tricks and tweaks which 
would need special handling for cygwin.

Hardy


PS: perhaps somebody could post the lines in question of the configure 
script so I could compare my broken and a working version!?

Re: Build problem

[Juergen W. <wie...@fr...>]

On Monday 26 June 2006 21:25 Hardy Griech wrote:
> checking how to run the C++ preprocessor... g++ -E
> ./configure: line 13465: syntax error near unexpected token `CAIRO,'
> ./configure: line 13465: `    PKG_CHECK_MODULES(CAIRO, cairo >=3D 0.9.0,'
>
> Also the previous prepare shows the problem J=FCrgen already reported:
>
> configure.in:243: error: possibly undefined macro: AC_MSG_WARN
>        If this token and others are legitimate, please use
> m4_pattern_allow. See the Autoconf documentation.
>
> I start to think, that the autoconf/automake-and-so-on-installation is
> somehow broken in cygwin or gnuplot uses some tricks and tweaks which
> would need special handling for cygwin.

I doubt this is a cygwin problem as I have the same problems on my
linux box.  I once also had the ./configure-error given above.  Now
thy ./prepare & build process stops with the autoconf and the
AC_MSG_WARN error.  The problems rose with the inclusion of the
wxwidgets-terminal.  This shouldn't be a problem in this sense, but
my libraries (cairo, wxwidgets, ...) are not recent enough for the
terminal.


Juergen

Re: Build problem

[Ethan A M. <merritt@u.washington.edu>]

On Monday 26 June 2006 10:28 pm, Juergen Wieferink wrote:
> On Monday 26 June 2006 21:25 Hardy Griech wrote:
> > checking how to run the C++ preprocessor... g++ -E
> > ./configure: line 13465: syntax error near unexpected token `CAIRO,'
> > ./configure: line 13465: `    PKG_CHECK_MODULES(CAIRO, cairo >= 0.9.0,'
> > 
> I doubt this is a cygwin problem as I have the same problems on my
> linux box.  I once also had the ./configure-error given above.  Now
> thy ./prepare & build process stops with the autoconf and the
> AC_MSG_WARN error.  The problems rose with the inclusion of the
> wxwidgets-terminal.  This shouldn't be a problem in this sense, but
> my libraries (cairo, wxwidgets, ...) are not recent enough for the
> terminal.

I am reasonably certain that the problem is due to a dependency on
the pkgconfig package. Yet another poorly designed tool created with
the best of intentions.  The problem is that if pkgconfig is present
on your system, then when *other* packages that know about it are
installed they create various extra configuration and macro files for
later use. This means that an installation in the presence of pkgconfig
is different from an installation in the absence of pkgconfig.

If you have installed most of your system without pkgconfig, and then
later on try to install something (let's call it B) that wants it,
there's a problem. Installing pkgconfig itself is not sufficient to fix
the problem. You have to instal pkgconfig, and then go back and
*reinstall* the various other packages so that they register themselves
with pkgconfig and hence problem package B can query pkgconfig for 
their presence.  

Bad design all around, as I say.   I'd be in favor of removing all
the PKG_CHECK_MODULES macros from configure.in, and finding another
mechanism to look for these features.  I suspect  AC_CHECK_LIB
would be sufficient, and we already know it works.

As a quick work-around, I suggest you try the attached patch.
It just deletes all the pkgconfig MACROS from configure.in
You may get build errors if the gtk+ libraries are not found, but
that's fixable.   Tested and works here, for whatever that's worth.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Build problem

[Hardy G. <nt...@ma...>]

Ethan A Merritt wrote:
:
> As a quick work-around, I suggest you try the attached patch.
> It just deletes all the pkgconfig MACROS from configure.in
> You may get build errors if the gtk+ libraries are not found, but
> that's fixable.   Tested and works here, for whatever that's worth.
:

Many thanks, Ethan!

./prepare is now running as intended, also my configure

./configure --without-lisp-files --with-readline=gnu --without-x 
--disable-mouse --disable-x11-mbfonts --disable-binary-x11-polygon

is running smoothly and the best:  the generated binary gnuplot.exe 
outputs plots as it should!

Hardy


PS: for the record: my system is a Windows XP with cygwin installation

Re: Build problem

[Hardy G. <nt...@ma...>]

Daniel J Sebald wrote:
> Hardy Griech wrote:
> 
>> ./prepare is now running as intended, also my configure
>>
>> ./configure --without-lisp-files --with-readline=gnu --without-x 
>> --disable-mouse --disable-x11-mbfonts --disable-binary-x11-polygon
> 
> Hardy,
> 
> Just curious why you used --disable-binary-x11-polygon.  Were you having 
> compile problems with that?  If so, let me know.

No problem with that.  I just tried to remove any interactivity from 
gnuplot, so I thought that removing any X11 reference would be clever...

Just running configure without any arguments results in:

** Configuration summary for gnuplot 4.1.0:

   Where is the help file? 
/usr/local/share/gnuplot/4.1/gnuplot.gih

   Use builtin minimal readline
   Enable history file
   Enable generation of JPEG files
   Enable generation of GIF files
          (including animated GIF)
   Enable generation of PNG files
   Enable TTF fonts with gd driver
   Build gnuplot-mode for X/Emacs
   Use the X Window System
   Enable mouse for X11
   Enable multi-byte font support for X11
   Enable fitting error variables
   Enable string-handling in datafiles
   Enable plot style histograms
   Enable string variables
   Enable command line macros (EXPERIMENTAL)
   Enable placement of rectangles and other objects (EXPERIMENTAL)
   Enable plot style image (EXPERIMENTAL)
   Enable general binary data file reading (EXPERIMENTAL)
   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)

make also produces successfully a binary, but that one wants to open 
display ':0' (unsuccessfully).

Hardy

Re: Build problem

[Daniel J S. <dan...@ie...>]

Hardy Griech wrote:

> ./prepare is now running as intended, also my configure
> 
> ./configure --without-lisp-files --with-readline=gnu --without-x 
> --disable-mouse --disable-x11-mbfonts --disable-binary-x11-polygon

Hardy,

Just curious why you used --disable-binary-x11-polygon.  Were you having compile problems with that?  If so, let me know.

Dan

Re: Build problem

[Daniel J S. <dan...@ie...>]

Hardy Griech wrote:

> make also produces successfully a binary, but that one wants to open 
> display ':0' (unsuccessfully).

OK.  It sounds like the configure file could use something to define what the default terminal should be when launching gnuplot.

Dan

Re: Build problem

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 27 June 2006 08:39 am, Daniel J Sebald wrote:
> Hardy Griech wrote:
> > make also produces successfully a binary, but that one wants to
> > open display ':0' (unsuccessfully).
>
> OK.  It sounds like the configure file could use something to define
> what the default terminal should be when launching gnuplot.

gnuplot itself tests for X11 on entry. Default terminal is set to x11
if
1) You are running from an xterm (env TERM or xterm)
or
2) You have the DISPLAY environmental variable set
or
3) GNUTERM is set to x11



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Build problem

[<tim...@en...>]

Hardy Griech wrote:
> Ethan A Merritt wrote:
> :
>  =20
>> As a quick work-around, I suggest you try the attached patch.
>> It just deletes all the pkgconfig MACROS from configure.in
>> You may get build errors if the gtk+ libraries are not found, but
>> that's fixable.   Tested and works here, for whatever that's worth.
>>    =20
> :
>
> Many thanks, Ethan!
>
> ./prepare is now running as intended, also my configure
>  =20
Thank you Ethan for pointing out that the pkg-config stuff is faulty.


Ethan A Merritt wrote:
> If you have installed most of your system without pkgconfig, and then
> later on try to install something (let's call it B) that wants it,
> there's a problem. Installing pkgconfig itself is not sufficient to fix
> the problem. You have to instal pkgconfig, and then go back and
> *reinstall* the various other packages so that they register themselves
> with pkgconfig and hence problem package B can query pkgconfig for=20
> their presence. =20
>  =20
I doubt that. The pkgconfig mechanism is based on *.pc files that some=20
package are providing, among them is cairo, pango, and gtk, but many=20
others (try 'pkg-config --list-all' to see how broadly it is used). I am=20
pretty sure those *.pc files are installed unconditionnally, i.e. even=20
when pkg-config is not present in the first place. The contrary would be=20
completely stupid, as you point out.

By the way, the problem Hardy and Juergen are facing is not that the=20
*.pc files are not found, but that the pkg-config macros themselves are=20
not found.
> Bad design all around, as I say.   I'd be in favor of removing all
> the PKG_CHECK_MODULES macros from configure.in, and finding another
> mechanism to look for these features.  I suspect  AC_CHECK_LIB
> would be sufficient, and we already know it works.
>  =20
That would be painful. PKG_CHECK_MODULES checks for a package of the=20
right version and sets the appropriate compiler flags, which are stored=20
the *.pc files. I would prefer to find another approach.

Hardy and Juergen, could you try to apply the attached patch ? It only=20
runs the PKG_CHECK_MODULES macros if the program pkg-config can be found.

Thank you very much.

Timoth=E9e

Re: Build problem

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 27 June 2006 12:34 pm, Timoth=E9e Lecomte wrote:
>
> Nevermind, this patch does not solve anything. I uninstalled
> pkg-config, and can reproduce exactly your problem (AC_MSG_WARN
> undefined and PKG_CHECK_MODULES with wrong syntax).
>
> However, I think I have found the right solution. As explained in
> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D2
>2 ("Best Practices with autotools"), we should always distribute the
> macros we are using, because the user may have an old and buggy macro
> or he may not have it at all.
>
> So the solution is to put 'pkg.m4' taken from the pkg-config package
> in <gnuplot source directory>/m4

I would prefer to remove the dependence on pkgconfig altogether.

Since when is it reasonable to require a particular package manager?
Particularly one which is only at release level 0.19, is not installed
by default, and clearly has portability issues.

As I previously described, in order to get wxWidgets up and running
I first had to find and install pkgconfig. But that wasn't sufficient;
I then had to go back and re-install earlier packages. What a pain.

As tested here, and confirmed by Hardy Griech, configure + install
works just fine without the pkgconfig macros.  Of course there can
always be compatibility issues with different library versions,
but we really need to check these at run-time or install-time,
not at the time ./configure is run.  So I continue to think that
pkg-config is a poor solution to the problem, and should be avoided.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Build problem

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 27 June 2006 10:48 am, Ethan Merritt wrote:

> I would prefer to remove the dependence on pkgconfig altogether.

I note that a Google search on "pkgconfig ~problems" returns
several pages of hits...



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Build problem

[<tim...@en...>]

Ethan Merritt wrote:
> On Tuesday 27 June 2006 12:34 pm, Timoth=E9e Lecomte wrote:
>  =20
>> Nevermind, this patch does not solve anything. I uninstalled
>> pkg-config, and can reproduce exactly your problem (AC_MSG_WARN
>> undefined and PKG_CHECK_MODULES with wrong syntax).
>>
>> However, I think I have found the right solution. As explained in
>> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D=
2
>> 2 ("Best Practices with autotools"), we should always distribute the
>> macros we are using, because the user may have an old and buggy macro
>> or he may not have it at all.
>>
>> So the solution is to put 'pkg.m4' taken from the pkg-config package
>> in <gnuplot source directory>/m4
>>    =20
>
> I would prefer to remove the dependence on pkgconfig altogether.
>
> Since when is it reasonable to require a particular package manager?
>  =20
Take a look at configure.in :
- gd has its own configuring tool, it's called gdlib-config
- libpdf has its own configuring tool, it's called pdflib-config
- wxWidgets has its own configuring tool, it's called wx-config

pkg-config is just an effort to write a universal tool to achieve the=20
same result. It *is* broadly used, see the attached file, which is the=20
output of 'pkg-config --list-all' on my machine.

> Particularly one which is only at release level 0.19, is not installed
> by default, and clearly has portability issues.
>  =20
Come on, the version number does not mean anything by itself. Its=20
changelog goes back to 2000, that's 6 years of use. The portability=20
issues were my fault, as I did not include the macros as I should have=20
done. pkg-config works on Unix, Mac, Windows, and Cygwin once you=20
installed it correctly.

> As I previously described, in order to get wxWidgets up and running
> I first had to find and install pkgconfig. But that wasn't sufficient;
> I then had to go back and re-install earlier packages. What a pain.
>  =20
I think that's the fault of your distribution.

> As tested here, and confirmed by Hardy Griech, configure + install
> works just fine without the pkgconfig macros.  Of course there can
> always be compatibility issues with different library versions,
> but we really need to check these at run-time or install-time,
> not at the time ./configure is run.

Checking for libraries' versions at run-time ? Unless I have cairo>0.9,=20
the necessary functions are not even defined in the headers. That's a=20
compile-time requirement.

Relying on the magic of wxWidgets compile and linking flags ? What if I=20
want to write a static terminal based on cairo and independant of=20
wxWidgets then ?

Best regards,

Timoth=E9e

Re: Build problem

[Juergen W. <wie...@fr...>]

On Tuesday 27 June 2006 21:34 Timoth=E9e Lecomte wrote:
> Nevermind, this patch does not solve anything. I uninstalled pkg-config,
> and can reproduce exactly your problem (AC_MSG_WARN undefined and
> PKG_CHECK_MODULES with wrong syntax).
>
> However, I think I have found the right solution. As explained in
> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D22
> ("Best Practices with autotools"), we should always distribute the
> macros we are using, because the user may have an old and buggy macro or
> he may not have it at all.
>
> So the solution is to put 'pkg.m4' taken from the pkg-config package in
> <gnuplot source directory>/m4
>
> I have commited the file to the CVS.
> Hardy and Juergen, can you try with the current CVS ?

Yepp.  Works.  Great work, thanks!

=46WIW: If I understand correctly, you say that this problem occurs if
there is no pkgconfig.  But actually, I have pkgconfig installed.
OTOH the distribution (SuSE 9.3) is rather outdated:

wiefer@localhost:~> rpm -qa |grep -i pkgconfig
pkgconfig-0.15.0-201
wiefer@localhost:~> rpm -qa |grep -i wx
wxGTK-2.5.3.1-5
wxGTK-gl-2.5.3.1-5
wxGTK-compat-2.5.3.1-5
wxGTK-devel-2.5.3.1-5
wiefer@localhost:~> rpm -qa |grep -i cairo
wiefer@localhost:~>=20


Thanks,
Juergen

Re: Build problem

[<tim...@en...>]

Timoth=E9e Lecomte wrote:
> Hardy and Juergen, could you try to apply the attached patch ? It only=20
> runs the PKG_CHECK_MODULES macros if the program pkg-config can be foun=
d.
>
Nevermind, this patch does not solve anything. I uninstalled pkg-config,=20
and can reproduce exactly your problem (AC_MSG_WARN undefined and=20
PKG_CHECK_MODULES with wrong syntax).

However, I think I have found the right solution. As explained in=20
http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D22=20
("Best Practices with autotools"), we should always distribute the=20
macros we are using, because the user may have an old and buggy macro or=20
he may not have it at all.

So the solution is to put 'pkg.m4' taken from the pkg-config package in=20
<gnuplot source directory>/m4

I have commited the file to the CVS.
Hardy and Juergen, can you try with the current CVS ?

Thank you very much and sorry for the trouble and the noise.

Timoth=E9e

Re: Build problem

[Hardy G. <nt...@ma...>]

Timothée Lecomte wrote:
:
> So the solution is to put 'pkg.m4' taken from the pkg-config package in 
> <gnuplot source directory>/m4
> 
> I have commited the file to the CVS.
> Hardy and Juergen, can you try with the current CVS ?
:

I have updated from cvs and can confirm, that prepare and configure will 
now run without problems under cygwin.

Thanks Timothée!

Hardy