gnuplot-beta

compiling gnuplot on Windows & mac/linux

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

Hello,

Despite of so many suggestions to use MinGW (I tried it, compiled
gnuplot successfully, but still had many other problems), I'm still
using MS Visual Studio. When I try to compile, I get a few hundred
lines of warnings which "make no sense" (I only don't see the serios
warnings then):

Here are some examples:

# 4113 - ..\\term\metapost.trm(973) : warning C4113: 'void (__cdecl
*)()' differs in parameter lists from 'void (__cdecl *)(void)'

# 4996 - term.c(1455) : warning C4996: 'strcpy' was declared deprecated
# Message: 'This function or variable may be unsafe. Consider using
strcpy_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'

# term.c(369) : warning C4996: 'stricmp' was declared deprecated
#        C:\Program Files\Microsoft Visual Studio
8\VC\INCLUDE\string.h(213) : see declaration of 'stricmp'
#        Message: 'The POSIX name for this item is deprecated.
Instead, use the ISO C++ conformant name: _stricmp. See online help
for details.'

Adding
     /wd4113 /wd4996 /D_CRT_SECURE_NO_DEPRECATE
(wd means ignore the warning) succesfully removes those errorrs.

I know that noone of you is using that, but it would really help if
someone who wrote that makefile or at least contributed to it could
take a look.

The next problem is with

CBASEFLAGS =3D /G5 /GX /GR /MD /O2 /nologo

# cl : Command line warning D9035 : option 'GX' has been deprecated
and will be removed in a future release
# cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
# cl : Command line warning D9002 : ignoring unknown option '/G5'

I replaced /GX with EHsc (althoug I have no idea what it means) and deleted=
 /G5.

There are many other problems, but at least the first three options to
supress false alarms in warnings would already help a lot.



OK, so let's move to linux/unix then. I have no idea what I'm dong
wrong, but I only ever managed to compile gnuplot on a single linux
box. I tried on 4 other systems (debian, fedora, suse - old version
worked, after tring to compile with wxt it failed, Mac OS X) and never
managed to get any further.

I'm currently trying to compile on Mac OS X. autoconf results in the follow=
ing:

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

and after running ./configure:

./configure: line 14693: syntax error near unexpected token `CAIROPANGO,'
./configure: line 14693: `    PKG_CHECK_MODULES(CAIROPANGO, cairo >=3D
0.9.0 pango >=3D 1.10 pangocairo >=3D 1.10,'


I have the following versions installed

autoconf (GNU Autoconf) 2.60
automake (GNU automake) 1.9.6

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
/sw/share/aclocal/libtool.m4:135: warning: underquoted definition of
AC_LIBTOOL_DLOPEN
/sw/share/aclocal/libtool.m4:138: warning: underquoted definition of
AC_LIBTOOL_WIN32_DLL
/sw/share/aclocal/libtool.m4:144: warning: underquoted definition of
AC_ENABLE_SHARED
/sw/share/aclocal/libtool.m4:170: warning: underquoted definition of
AC_DISABLE_SHARED
/sw/share/aclocal/libtool.m4:177: warning: underquoted definition of
AC_ENABLE_STATIC
/sw/share/aclocal/libtool.m4:203: warning: underquoted definition of
AC_DISABLE_STATIC
...
etc


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


Am I really the only one with installation problems?

Thanks a lot for help,
    Mojca

Re: compiling gnuplot on Windows & mac/linux

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

On Sunday 12 November 2006 05:51 am, Mojca Miklavec wrote:
>
> I have the following versions installed
>
> autoconf (GNU Autoconf) 2.60
> automake (GNU automake) 1.9.6




>
> 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.=20
If you had actually followed the link in the warning message, it
would have told you how to get rid of it.

> 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.

> Am I really the only one with installation problems?

On linux, maybe you are :-)
On OSX, there seem to be a number of issues.
Windows, I have no clue about.


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

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

Re: compiling gnuplot on Windows & mac/linux

[<HBB...@t-...>]

Mojca Miklavec wrote:
> On 11/12/06, Hans-Bernhard Bröker wrote:
>> Mojca Miklavec wrote:

>> > # 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 

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.

> 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 product?

>> > 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*?

> 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.

> 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.

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

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

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

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

I'm sorry, I was too unclear. I meant it as: it would help a lot if
files like the one on
    http://sourceforge.net/project/showfiles.php?group_id=2055&package_id=66525
(gnuplot 4.2rc1) would also be available in binary form for windows
(at least; perhaps also for mac).

(If it would be easier to compile gnuplot for windows, the one who
puts source files on sourceforge coud also place the windows binary
next to them.)

Mojca

Re: compiling gnuplot on Windows & mac/linux

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

On Wednesday 15 November 2006 10:16 am, Mojca Miklavec wrote:
> > It would be extremely useful if developers wouldn't only put source
> > files on the web, but also binaries, at least for windows.
> 
> I'm sorry, I was too unclear. I meant it as: it would help a lot if
> files like the one on
>     http://sourceforge.net/project/showfiles.php?group_id=2055&package_id=66525
> (gnuplot 4.2rc1) would also be available in binary form for windows
> (at least; perhaps also for mac).

Thank you for volunteering.

The current developing team basically doesn't use windows much, 
many of us not at all. So we welcome your assistance in preparing
binary versions for this awkward platform.


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

Re: compiling gnuplot on Windows & mac/linux

[<HBB...@t-...>]

Mojca Miklavec wrote:

> makefile.mgw
> #DESTDIR = /c/Progra~1/Gnuplot4.1
> 
> any many other places still contain old strings. Can anyone grep for
> them and replace them?

Sure.  Anyone can.  We'd certainly like to receive lists of things we 
missed, so they can be corrected in the next release candidate. 
Spotting things like that is what release candidates are about.

> OK, I spent three or four hours and finnaly got MinGW working on this
> mac 

Now you have me confused.  You obviously have a Windows box at your 
disposition (or how else did you run MS Studio.Net?), and you're about 
to build programs for Windows, which you'll have to test-run at some 
point --- so why on earth did you pick a *Mac* to install and run MinGW on?

> 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? 

It doesn't exist, but I rather doubt it'd be interesting enough to the 
general public to be worth putting in CVS.  The overwhelming majority of 
people who want to build programs for Windows will be using Windows 
machines to do it.

But feel free to post the modified makefile.mgw on the "Patches" Tracker 
page.

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

We will --- for the actual release.  If and when we actually manage to 
get there.

> 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.

Obviously not.  You have to at least run automake, too.  And aclocal.

The ./prepare script exists for a reason.

> /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.

"Fixed" them --- how?  By modifying those symlinks yourself?  That's not 
how these things are supposed to be managed.  There's a program for 
that.  It should be called 'alternatives' or similar, and it'll probably 
be in /sbin or /usr/sbin, because only root can usefully run it.

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

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

On 11/15/06, Hans-Bernhard Br=F6ker <HBB...@t-...> wrote:
> Mojca Miklavec wrote:
>
> > OK, I spent three or four hours and finnaly got MinGW working on this
> > mac
>
> Now you have me confused.  You obviously have a Windows box at your
> disposition (or how else did you run MS Studio.Net?), and you're about
> to build programs for Windows, which you'll have to test-run at some
> point --- so why on earth did you pick a *Mac* to install and run MinGW o=
n?

I admit, weird indeed.

I've changed my computer a few days ago from dual-boot Linux+Win
(running Win 99% of time) to dual-boot Mac+Win (running Mac 95% of
time). I urgently needed gnuplot and when I changed the machine taking
MS Studio.Net was the fastest way to build it (since I had all the
files ready).

Yesterday somebody asked me for windows binary and the one compiled
with MSVC didn't work on his computer (apart from the fact that GD,
PDF, ... don't work either). Since using MinGW was apparently the only
choice, I decided to try to compile on Mac, which will take me less
effort (once set up) next time when I'll want to create a windows
binary.

About testing ... I often use windows on other computers (and I don't
want to set up all the development tools on every single computer
where I might want to use gnuplot) and since I don't intend to develop
the windows user-interface, it should be enough to test the terminal
in one platform only. Once it's OK, the windows binary should remain
OK after applying new pathes.

> > 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?
>
> It doesn't exist, but I rather doubt it'd be interesting enough to the
> general public to be worth putting in CVS.  The overwhelming majority of
> people who want to build programs for Windows will be using Windows
> machines to do it.
>
> But feel free to post the modified makefile.mgw on the "Patches" Tracker
> page.

I'll see what I can do. I'm currently trying to figure out how to enable gd=
 ...

> > /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.
>
> "Fixed" them --- how?  By modifying those symlinks yourself?

Yes. I had no idea what else to do.

> That's not
> how these things are supposed to be managed.  There's a program for
> that.  It should be called 'alternatives' or similar, and it'll probably
> be in /sbin or /usr/sbin, because only root can usefully run it.

Thanks. There's indeed a program update-alternatives in /usr/sbin.

On 11/15/06, Ethan A Merritt wrote:
> On Wednesday 15 November 2006 10:16 am, Mojca Miklavec wrote:
> > > It would be extremely useful if developers wouldn't only put source
> > > files on the web, but also binaries, at least for windows.
> >
> > I'm sorry, I was too unclear. I meant it as: it would help a lot if
> > files like the one on
> >     http://sourceforge.net/project/showfiles.php?group_id=3D2055&packag=
e_id=3D66525
> > (gnuplot 4.2rc1) would also be available in binary form for windows
> > (at least; perhaps also for mac).
>
> Thank you for volunteering.
>
> The current developing team basically doesn't use windows much,
> many of us not at all. So we welcome your assistance in preparing
> binary versions for this awkward platform.

I would be glad to help and submit binaries when needed. At least once
I figure out how to buid help files & gd ...

Mojca

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

[Petr M. <mi...@ph...>]

>> I'd rather you remove the stupid compiler that emits them.
> makefile.mgw
> #DESTDIR = /c/Progra~1/Gnuplot4.1
>
> any many other places still contain old strings. Can anyone grep for
> them and replace them?

By what? Isn't there some way to know whether that dir should be called 
"Program Files", "Programy", "Programme", etc?

> 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?

Do you really need it? I "crosscompile" gnuplot for Windows on Linux by 
means of MingW: I run the wine console (wcmd), and then do what is written 
for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is 
done.

Isn't there a Wine for MacOSX on Intel?

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

I did so, see
 	http://gnuplot.sourceforge.net/development/binaries/

>> But it would help a lot if those warnings would be removed with the
>> three switches mentioned above,

I think that cleaned makefile could be put into cvs, if you prepare it. 
Check also config.xxx.

>> Microsoft has made it clear that they don't care about providing a
>> working compiler, why should we care about supporting their broken product?
>
> OK, I accept that.

There could be a message in that makefile that the 
compilation/binary/pgnuplot/... may not work for which version of the 
compiler.

---
PM

Re: compiling gnuplot on Windows & mac/linux

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

On Sunday 19 November 2006 05:34 am, Petr Mikulik wrote:
> > makefile.mgw
> > #DESTDIR = /c/Progra~1/Gnuplot4.1
> >
> > any many other places still contain old strings. Can anyone grep for
> > them and replace them?
> 
> By what? 

I thought the point was to replace '4.1' by '4.2'


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

Re: compiling gnuplot on Windows & mac/linux

[<HBB...@t-...>]

Petr Mikulik wrote:

> By what? Isn't there some way to know whether that dir should be called 
> "Program Files", "Programy", "Programme", etc?

On the more modern systems (Win2K and up, I think), there is an 
environment variable %ProgramFiles%.  The problem with that would be 
that it reads something like "c:\Program Files" (backslash, drive 
letter), whereas MSYS (nowadays to be assumed as the underlying Unix 
substitution layer for MinGW) would want "/c/Program Files", and Cygwin 
"/cygdrive/c/Program Files".  And it's not really clear that getting 
'make install' fully right is even worth trying on Windows.

> Do you really need it? I "crosscompile" gnuplot for Windows on Linux by 
> means of MingW: I run the wine console (wcmd), and then do what is written 
> for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is 
> done.

That's not really cross-compiling.  Cross-compiling would mean you build 
a version of GCC running directly on Linux that builds Win32 executables 
based on the MinGW libraries and headers.

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

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

On 11/19/06, Petr Mikulik wrote:
> >> I'd rather you remove the stupid compiler that emits them.
> > makefile.mgw
> > #DESTDIR = /c/Progra~1/Gnuplot4.1
> >
> > any many other places still contain old strings. Can anyone grep for
> > them and replace them?
>
> By what? Isn't there some way to know whether that dir should be called
> "Program Files", "Programy", "Programme", etc?

I meant the number. Some files still contain 4.1 as the version number
(or 4.2 in cvs, which should be 4.3 now).

> > 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?
>
> Do you really need it? I "crosscompile" gnuplot for Windows on Linux by
> means of MingW: I run the wine console (wcmd), and then do what is written
> for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is
> done.
>
> Isn't there a Wine for MacOSX on Intel?

Yes, there is - thanks for the hint, it will probably go more smoothly
(easier) there. I was compiling without wine (crosscompiling using
mingw) - successfully, but I didn't manage to integrate external
libraries (gd, wxt) yet.

> >> Microsoft has made it clear that they don't care about providing a
> >> working compiler, why should we care about supporting their broken product?
> >
> > OK, I accept that.
>
> There could be a message in that makefile that the
> compilation/binary/pgnuplot/... may not work for which version of the
> compiler.

It conditionally works with the latest version (apart from gd & wxt -
I have no idea whose fault that is because I cannot check with older
compilers), but I understood the answer more like
   "We don't want to fix (minor things that would make compiling a bit easier)."
and I'm OK with it.

> > Do you really need it? I "crosscompile" gnuplot for Windows on Linux by
> > means of MingW: I run the wine console (wcmd), and then do what is written
> > for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is
> > done.
>
> That's not really cross-compiling.  Cross-compiling would mean you build
> a version of GCC running directly on Linux that builds Win32 executables
> based on the MinGW libraries and headers.

I don't really mind if this is called cross-compiling or not - I only
care about the end effect which should be a working windows
application. (And if it's easier to do it using wine, there should be
no reason for not using it.)

Mojca