Re: Re: compiling gnuplot on Windows & mac/linux

[Mojca M. <moj...@gm...>]

Summary: I solved the issue by running ./prepare instead of autoconf
(someone else's idea, not mine) on both debian & Mac.

Thanks a lot for all the replies.

On 11/12/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
>
> > # 4113 - ..\\term\metapost.trm(973) : warning C4113: 'void (__cdecl
> > *)()' differs in parameter lists from 'void (__cdecl *)(void)'
>
> Misleading text, though it's a justified warning.  An argument list of
> () cannot differ from *any* argument list.  MS has read too many C++
> documents, and not enough about C.
>
> > # 4996 - term.c(1455) : warning C4996: 'strcpy' was declared deprecated
>
> No it wasn't.  MS is spreading misinformation.

MS wants to have its own version of "safe" string copying and other
routines that are otherwise standard in any other compiler but the
Microsoft's one. (it complains about scanf and many others)

adding /D_CRT_SECURE_NO_DEPRECATE
removes those "stupid" warnings.

> > # term.c(369) : warning C4996: 'stricmp' was declared deprecated
>
> Same here.
>
> > Adding
> >      /wd4113 /wd4996 /D_CRT_SECURE_NO_DEPRECATE
> > (wd means ignore the warning) succesfully removes those errorrs.
>
> No it doesn't --- because they're not errors.  They're warnings.

Sorry, I meant warnings (I wrote "errors" by accident)

But it would help a lot if those warnings would be removed with the
three switches mentioned above, otherwise it's very difficult for any
developer working under windows to see any helpful warning or error (I
always used "nmake > log.txt" and searched for "error" in log.txt)

> > configure.in:1: error: possibly undefined macro: dnl
>
> Complete and utter nonsense.  dnl is an m4 builtin, not a macro.  You
> must have managed to mangle the line endings of your sources when you
> brought them to that Mac.

Do you mean gnuplot sources? I took them from CVS.
I have no idea what else could go wrong, files look OK (unless the
step with getting cvs content failed, but now when I used another way
to build gnuplot it works OK). Anyway - I won't bother about it any
more now.

> > /sw/share/aclocal/libtool.m4:25: warning: underquoted definition of
> > AC_PROG_LIBTOOL
>
> Nothing to do with gnuplot.  Your libtool version is too old for the
> version of automake you have.

I took a look now.
http://fink.sourceforge.net/doc/porting/libtool.php?phpLang=3Den seems
to be a bit outdated indeed and for some reason libtool resides in
/usr/bin as a binary with strange options, not in /sw/... as plain
text file (as on the other debian machine) and "fink install libtool"
doesn't find the package. I'll check again what I can do (I need a bit
more time to figure out how things work here - I'm working on mac for
no more than a few days).


On 11/13/06, Ethan Merritt wrote:
> On Sunday 12 November 2006 05:51 am, Mojca Miklavec wrote:

> > Timoth=E9e suggested to take a look into the version of
> > automake/autoconf. I also installed SDL and libtool (althogh I have
> > no idea what they were used for), and here is what aclocal returns:
> >
> > /sw/share/aclocal/libtool.m4:25: warning: underquoted definition of
> > AC_PROG_LIBTOOL
> >   run info '(automake)Extending aclocal'
> >   or see
> > http://sources.redhat.com/automake/automake.html#Extending-aclocal
> > /sw/share/aclocal/libtool.m4:55: warning: underquoted definition of
> > AC_LIBTOOL_SETUP
>
> That has nothing to do with gnuplot.
> That is due to some idiotic decision by the packagers of aclocal
> to spit out warnings for syntax that will be deprecated in the future.
> If you had actually followed the link in the warning message, it
> would have told you how to get rid of it.

But that was about rewriting macros. I have no idea what I were
supposed to do with that and even if: the problem was not that I got
only warnings - the problem was that it didn't even configure/compile.

> > An this is what I get under Debian:
> >
> > configure.in:7: error: possibly undefined macro: AM_CONFIG_HEADER
> >       If this token and others are legitimate, please use
> > m4_pattern_allow. See the Autoconf documentation.
> > configure.in:15: error: possibly undefined macro: AM_INIT_AUTOMAKE
> > configure.in:25: error: possibly undefined macro: AM_C_PROTOTYPES
> > configure.in:75: error: possibly undefined macro: AM_CONDITIONAL
> > configure.in:243: error: possibly undefined macro: AC_MSG_WARN
> >
> > autoconf (GNU Autoconf) 2.59
> > automake (GNU automake) 1.4-p6
>
> That version of automake is ancient.
> Please use 1.9, as you were on your other machine.

I installed it already, but the symbolic link was still pointing to
the wrong old version. I fixed that, however, no change after that.
Still the same warnings with automake 1.9.5 and libtool 1.5.6 (the
latest that apt-get gave me; I'll try to get the new version of it, I
just have to be a bit careful because that one is running on a
server).

> > Am I really the only one with installation problems?
>
> On linux, maybe you are :-)
> On OSX, there seem to be a number of issues.

The "magic" that helped me to finally build it succesfully on Mac was
to run "prepare" script (without modifying or installing any other
library or program):

chmod a+x prepare
./prepare
./configure
make

Someone else has suggested me to use prepare instead of autoconf.
There were still numerous warnings, but finally gnuplot compiled
successfully.

> Windows, I have no clue about.

On windows I installed it succesfully (although I didn't manage to
make gd & pdf to work properly, but I can take the official binary if
I need those, so I don't care too much about it).

On 11/13/06, Per Persson wrote:

> PS. I noticed that you are using fink. Be aware that fink, IIRC,
> *prepends* /sw/bin to your path and thus overrides a lot of stuff.
> Maybe you should check the fink mailing lists for clues to what might
> be wrong.

I'm aware of that, but are there any other (better) alternatives?

Thanks a lot,
    Mojca