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

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

On 11/14/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > On 11/12/06, Hans-Bernhard Br=F6ker wrote:
> >> Mojca Miklavec wrote:
>
> >> > # 4996 - term.c(1455) : warning C4996: 'strcpy' was declared depreca=
ted
>
> >> No it wasn't.  MS is spreading misinformation.
>
> > MS wants to have its own version of "safe" string copying
>
> They can want that as much as the day is long, that doesn't change the
> fact that they're telling a lie, and they know it.  strcpy is an ISO/IEC
> Standard C Library function.  That means it's not in Microsoft's power
> to deprecate it.
>
>  > and other
> > routines that are otherwise standard in any other compiler but the
> > Microsoft's one.
>
> There's no such thing.  These functions are standard, and will remain
> so, completely regardless of whether Microsoft's compiler has them or not=
.
>
> > adding /D_CRT_SECURE_NO_DEPRECATE
> > removes those "stupid" warnings.
>
> I'd rather you remove the stupid compiler that emits them.

makefile.mgw
#DESTDIR =3D /c/Progra~1/Gnuplot4.1

any many other places still contain old strings. Can anyone grep for
them and replace them?


OK, I spent three or four hours and finnaly got MinGW working on this
mac and managed to compile a working windows version of gnuplot (still
without gd, freetype & help, but nonetheless I'm happy about it).

Now a question: is anyone ready to help me to write a clean makefile
for MinGW for cross-compiling (which would be suitable to add to CVS)
or does that exist already? (I already fixed in a way that enables me
to compile it on my computer, but it would be nice if it would compile
on other computers as well)

It would be extremely useful if developers wouldn't only put source
files on the web, but also binaries, at least for windows.

> > But it would help a lot if those warnings would be removed with the
> > three switches mentioned above,
>
> Feel free to do that in your own local version.  I don't see a good
> reason why we should support Microsoft's willfully distorted view of
> they world by putting such options into the CVS version of the makefile.
> Microsoft has made it clear that they don't care about providing a
> working compiler, why should we care about supporting their broken produc=
t?

OK, I accept that.

> >> > 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.
>
> Took them --- *how*?

cvs -z3 -d:pserver:ano...@gn...:/cvsroot/gnuplot
co -P gnuplot
But forget about that. It's finally working now - I have no idea where
the error came from and I don't care any more. Running only autoconf
doesn't seem the best thing to do anyway.

> > I installed it already, but the symbolic link was still pointing to
> > the wrong old version.
>
> Which symbolic link?  To switch between several versions of automake,
> you usually have to change a good deal more than one symlink.  It
> generally takes at least 2 or three, depending on how well they were
> prepared to run as alternatives.

"which automake" returns me /usr/bin/automake and:

/usr/bin/automake -> /etc/alternatives/automake
/etc/alternatives/automake -> /usr/bin/automake-1.9 (was 1.4a)

So I only fixed /etc/alternatives/automake and aclocal.

Is there some other way to switch the version? (sorry, I'm really not
expert in those things - I only use linux occasionally and this was
the first time when I played around with autoconf and automake)

> > Someone else has suggested me to use prepare instead of autoconf.
>
> ... You would have gotten that advice a lot sooner if you had told us
> exactly what you did.

I don't have much experience with compiling under linux/unix. There
was no configure script, so I ran "autoconf" (I only mentioned that
the process failed while running autoconf, I really didn't say that
that was the only thing I did since autoconf could have been called
from prepare script as well), but never mind the stupid question from
me.

Thanks,
    Mojca