gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Error plotting lcdemo.dat

[sfeam <sf...@us...>]

On Thursday, 03 March 2016 11:31:38 PM Bastian Märkisch wrote:
> When trying to plot "lcdemo.dat" using the current CVS version, I do get 
> the following warning:
> 
> gnuplot> plot "lcdemo.dat"
>                ^
>           warning: Unrecognized 5 column plot style; resetting to 
> boxerrorbars
> 
> Is that to be expected? Does anybody else see that?

Yeah. Sorry, That was a side-effect of adding "pointtype variable".
That increased the maximum number of columns relevant to "with points"
from 4 to 5.  That's fine if the plot command actually consumes all 5
columns, but if the data file contains more columns than the plot command
uses, then the extra ones have to be ignored gracefully. 
Fixed now.

	Ethan

Re: Mac installation cloning

[<pl...@pi...>]

On 04/03/16 00:22, Thomas Mattison wrote:
> The main capability lacking from plain vanilla gnuplot built on my 10.6.8 Mac from source is the ability to make png or gif output.
>
> What is the minimal set of packages I need to have to get png or gif terminal types?
>
> I'd also like to be able to make pdf output.  What is the minimal set of packages to make pdf output?
>
> Or is there some way to trick the postscript terminal to make pdf output?  (I know that the postscript terminal can make eps output, which is not hard to convert to pdf.  And I know that if I install Aquaterm before the gnuplot build, then the "aqua" terminal type appears, and Aquaterm can save its window to a pdf file)
>
>
> It would be nice to make a Mac version of Gnuplot that supported all terminal types that are supported in the Windows version.
>
> What terminal types are supported in the Windows version of gnuplot?
>
> What packages are required so they could be available to a Mac version?
>
>
>
>
>
>                                        Cheers
>
> Prof. Thomas Mattison           Hennings 276
> University of British Columbia  Dept. of Physics and Astronomy
> 6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
> mat...@ph...         phone: 604-822-9690  fax:604-822-5324
>
>

Run up a copy on windows and enter set term to see what terminals are 
available.

gnuplot> set term


The list will be long and you probably could cut a whole load and save 
yourself a lot of work.

I think using cairo and pango to supply png avoids the mess caused by 
png devs breaking binary compatibility between versions.

Peter.

Re: Progress on Mac installation cloning

[<pl...@pi...>]

On 03/03/16 22:36, Thomas Mattison wrote:
> Where/how can I find a list of dependencies that could be
> statically linked into the gnuplot binary on the build machine,
> so I wouldn't have to distribute the libraries?
>
> Where/when do I do the --enable-static and --disable-shared ?
> When building gnuplot?  When (re-)building the libraries?
>
> I'm not sure what you are recommending for cases where
> I can't do a static link.
>
> Are you saying that I should make an /opt/gnuplot directory
> on the build machine, put the required dynamic libraries there,
> and tell the gnuplot build that the libraries are in /opt/gnuplot?
>
> How would I do that?
>
> Then in addition to the rsync of the tree that comes out of
> the gnuplot "make DESTDIR=/tmp/gnuplot install" , I would also
> presumably need to copy the /opt/gnuplot directory onto the
> destination machine.
>
> And your point is that the dynamic libraries in /opt/gnuplot
> are less likely to get clobbered than if they are in their
> "standard" places?
>
>
> On 2016-03-03, at 1:21 PM, Mojca Miklavec wrote:
>
>> On 3 March 2016 at 21:56, Thomas Mattison wrote:
>>>
>>> So the lesson is that Aquaterm needs to be on the build machine before the build.
>>
>> Yes. You need all dependencies present on the machine where you build
>> gnuplot (and all those dependencies have to be either included as
>> static libraries or have to be present on the destination).
>>
>>> Any idea what is going on, or advice?
>>
>> I'm not sure how exactly you installed the libraries.
>>
>> If you want to do this properly, you should better build all the
>> dependencies yourself, ideally as static libraries. And you need to
>> know which files exactly to copy to the destination machine (so that
>> gnuplot keeps working). Again, do yourself and your students a favour
>> and install the libraries to /opt/gnuplot rather than /usr/local.
>> Please. You should set ./configure --prefix=/opt/gnuplot for every
>> dependency. And probably something like --enable-static
>> --disable-shared. Just make the final symlink from
>> /usr/local/bin/gnuplot to /opt/gnuplot/bin/gnuplot. If you'll install
>> things to /usr/local, students will sooner or later run into troubles.
>> (Let's say that your colleague [or some other project that can be
>> downloaded from web] comes to a similar idea and decides to offer
>> students some other software compiled in the same way using a
>> different version of one of the same libraries. Then gnuplot would
>> stop working or start crashing if both scripts install to the same
>> location.)
>>
>> If you have your dynamic libraries installed at
>>     /Users/mattison/anaconda/include/freetype2
>> then gnuplot most likely won't work unless your students install the
>> files to exactly the same location (or if you set up everything very
>> very carefully and properly and run install_name_tool to change
>> location of libraries).
>>
>> Mojca
>
>
>
>                                        Cheers
>
> Prof. Thomas Mattison           Hennings 276
> University of British Columbia  Dept. of Physics and Astronomy
> 6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
> mat...@ph...         phone: 604-822-9690  fax:604-822-5324
>
>


The conversion on this list is not to top post replies ;)

As I said in my last reply look at ./configure --help

You can set loads of things from there.

If you want to install the /opt/gnuplot/  you have options to do that.

Peter.

Re: Progress on Mac installation cloning

[Allin C. <cot...@wf...>]

On Thu, 3 Mar 2016, Thomas Mattison wrote:

> The goal is to make it easy for a non-computer-science student to 
> install gnuplot on a reasonably modern Mac. [...]
>
> As I learned yesterday, the existing gnuplot makefile supports
> "make DESTDIR=/tmp/gnuplot install"
> That makes a tree starting at /tmp/gnuplot/usr
> I copied that tree to a flash drive as gnuplot64/usr
> I made a short script file to the gnuplot64 directory:
>
> #!/bin/sh
> echo "This script must be run from an account with administrative privileges"
> echo "You must enter the administrative user's password"
> sudo rsync -arv usr/* /usr

In the Mac world, the "right way" to do this is to build gnuplot as 
an app "bundle", including all libraries that are required, then 
make a "flat package" of the bundle. That way your students could 
just download the pkg file and double-click to install it. All this 
can be done via Xcode, either GUI or command-line tools. (It can 
also be done using cross-tools on Linux, but I don't suppose you 
want to get into that.)

I take Ethan's point about shared libraries -- ideally, they should 
be installed to a common location and shared across application 
programs -- nonetheless it's not the way third-party apps do things 
on the Mac. Unless you're going all the way with a third-party 
package system such as MacPorts or Homebrew, but I gather your 
students wouldn't be up to that.

If you want to try out the app bundle approach, the basic idea is
to create a drectory

/Applications/Gnuplot.app/Contents/Resources

and build/install everything you need with that prefix. There's more 
to it, of course, but that's a good start.

Allin Cottrell

Re: Mac installation cloning

[Ethan A M. <sf...@us...>]

On Thursday, 03 March, 2016 16:22:32 Thomas Mattison wrote:
> The main capability lacking from plain vanilla gnuplot built on my 10.6.8 Mac from source is the ability to make png or gif output.
> 
> What is the minimal set of packages I need to have to get png or gif terminal types?

gif
===
gif is supported only by the gd terminal (libgd).
The only reason I know of that you would need this is so that you
can generate animated gifs directly from gnuplot.
It is possible to make animations from a series of png images, but
you would need to create the individual frames and then use an external
tool to stitch them together into an animation.

png
===
png images can be generated by the gd terminal (libgd), by the
cairo terminals, by wxt (via a "save as" button) and by qt
(also via a "save as" button).


> I'd also like to be able to make pdf output.  What is the minimal set of packages to make pdf output?  

Three choices:

qt:	if you have the qt support libraries, then you can create pdf output
	via a "save as" button from the qt terminal.  I personally think the
	qt terminal is the best interactive option that gnuplot supports, so
	I'd go with this if you can find the support libraries.

cairo:	"set term pdf" will default to the cairo terminal if you have it.
	The downside here is that it requires at least the cairo, pango, 
	pangocairo, and lgobject libraries, and you may or may not be able 
	to use copies built by someone else. 

TeX: The tikz terminal produces very nice pdf output, but it requires separate
	installation of lua and TeX/pdflatex.  On the gnuplot side the only extra
	library is liblua. As with Qt, this may be a good option if you can find
	a suitable ready-to-install TeX package.  Not practical to build from
	scratch however.

> Or is there some way to trick the postscript terminal to make pdf output? 

The plot part is trivial (same conversion as for *.eps files).
However a major reason for choosing pdf rather than postscript output is that 
postscript cannot handle UTF-8 text.  UTF-8 makes life so much easier for
math/greek/symbols, it would be a pity to limit your pdf output to things
that postscript can handle.

	Ethan

> (I know that the postscript terminal can make eps output, which is not hard to convert to pdf.  And I know that if I install Aquaterm before the gnuplot build, then the "aqua" terminal type appears, and Aquaterm can save its window to a pdf file) 
> 
> 
> It would be nice to make a Mac version of Gnuplot that supported all terminal types that are supported in the Windows version.
> 
> What terminal types are supported in the Windows version of gnuplot?
> What packages are required so they could be available to a Mac version?
> 
> 
> 
> 
> 
>                                       Cheers
> 
> Prof. Thomas Mattison           Hennings 276
> University of British Columbia  Dept. of Physics and Astronomy
> 6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
> mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Mac installation cloning

[Thomas M. <mat...@ph...>]

The main capability lacking from plain vanilla gnuplot built on my 10.6.8 Mac from source is the ability to make png or gif output.

What is the minimal set of packages I need to have to get png or gif terminal types?

I'd also like to be able to make pdf output.  What is the minimal set of packages to make pdf output?  

Or is there some way to trick the postscript terminal to make pdf output?  (I know that the postscript terminal can make eps output, which is not hard to convert to pdf.  And I know that if I install Aquaterm before the gnuplot build, then the "aqua" terminal type appears, and Aquaterm can save its window to a pdf file) 


It would be nice to make a Mac version of Gnuplot that supported all terminal types that are supported in the Windows version.

What terminal types are supported in the Windows version of gnuplot?

What packages are required so they could be available to a Mac version?





                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Re: Progress on Mac installation cloning

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

On 4 March 2016 at 00:29, Ethan A Merritt wrote:
> On Friday, 04 March, 2016 00:02:06 Mojca Miklavec wrote:
>
>> > Are you saying that I should make an /opt/gnuplot directory
>> > on the build machine, put the required dynamic libraries there,
>> > and tell the gnuplot build that the libraries are in /opt/gnuplot?
>>
>> Yes, that would be much better than installing dynamic libraries into
>> /usr/local
>
> I very much disagree with this.
> The whole point of shared libraries is that they are, well, _shared_.
> When a single copy of the library is shared, that means security fixes,
> library bug-fixes, and upgrades benefit all programs on the system.

Except that Thomas most likely won't be providing security fixes to
his students, will he?
And if he now installs libpng 1.6 and after a while "someone or
something else" installs libpng 1.7 (or 1.5), gnuplot will suddenly
become broken as it will no longer work with the other version of
library without recompiling it.

The paradigm works well on Linux, but please understand that this is
not the case on OS X (or at least go complain to Apple).

If someone wants security fixes for dependencies of gnuplot, a package
manage should be installed (which is something that Thomans explicitly
wants to avoid).

> If you keep a separate copy for each program then you would have to update
> and rebuild each of those separate copies in parallel. What a headache.

How often do you rebuild applications on Windows?

>> > And your point is that the dynamic libraries in /opt/gnuplot
>> > are less likely to get clobbered than if they are in their
>> > "standard" places?
>>
>> Yes.
>
> Where "clobbered" can mean "updated or fixed"

If Thomas puts a random library with an arbitrary name to /usr/local:
what or who exactly is going to fix it? Again, if someone will replace
one library with an ABI-incompatible version, gnuplot will stop
working anyway (and we know that these students have no clue how to
rebuild gnuplot, so they'll just stop using it).

Worse. If I would try to compile gnuplot from CVS a few years from now
and I would have the latest library installed (in /opt/local, provided
by the package manager) plus that old and outdated libpng in
/usr/local (from the USB stick by Thomas), the compiler will pick up
that outdated vulnerable library and will end up with gnuplot linked
against a vulnerable version.

> That is the exact opposite of a supportable system layout IMHO.
> If there is a bug in the library, that is exactly when you _do_ want a
> single shared copy so that fixing the bug benefits all users of the library.

Again: how exactly do you address that problem with gnuplot binaries
on Windows? Where do you get the shared libraries from and who makes
sure that they are always up to date?

It's one thing when a huge herd of developers and security specialists
make sure that you'll get the latest fixes when you run "sudo apt-get
upgrade" and it's a completely different thing when a Windows (or OS
X) user gets a bunch of binaries from a friend. Who and how exactly
will take care of patching those binary files?

> Now it is true that if you manage to build a defective copy of a library
> then putting it in /usr/local/lib could harm other programs as well as
> breaking your intended client. But putting that defective library in your
> private directory isn't going to get you a working client either,
> nor would including it permanently in your executable as a static library.

The thing is that he could get a working gnuplot now. And then one
month from now something or someone could install a defect library to
/usr/local and gnuplot would stop working if it linked against the
library in /usr/local. If it would have a statically linked library or
if it was at some exotic location, it wouldn't be affected by that
broken library.

Mojca

Re: Progress on Mac installation cloning

[Ethan A M. <sf...@us...>]

On Friday, 04 March, 2016 00:02:06 Mojca Miklavec wrote:
> 
> > Are you saying that I should make an /opt/gnuplot directory
> > on the build machine, put the required dynamic libraries there,
> > and tell the gnuplot build that the libraries are in /opt/gnuplot?
> 
> Yes, that would be much better than installing dynamic libraries into /usr/local

I very much disagree with this.
The whole point of shared libraries is that they are, well, _shared_.
When a single copy of the library is shared, that means security fixes, 
library bug-fixes, and upgrades benefit all programs on the system.
If you keep a separate copy for each program then you would have to update
and rebuild each of those separate copies in parallel.  What a headache.


> > And your point is that the dynamic libraries in /opt/gnuplot
> > are less likely to get clobbered than if they are in their
> > "standard" places?
> 
> Yes.

Where "clobbered" can mean "updated or fixed"

> Gnuplot binary alone is in fact not problematic at all, but as soon as
> you start shipping some libraries (like libpng.dylib inside
> /usr/local/lib/libpng.dylib if you wouldn't build it statically for
> some reason) this is just asking for problems later on. (Even if user
> just decides to install MacPorts or HomeBrew later on, libpng.dylib in
> /usr/local/lib will cause numerous headaches for that user and any bug
> reports that the user would try to file would be immediately closed
> with "please remove that library from /usr/local/lib".)

That is the exact opposite of a supportable system layout IMHO.
If there is a bug in the library, that is exactly when you _do_ want a
single shared copy so that fixing the bug benefits all users of the library.

Now it is true that if you manage to build a defective copy of a library
then putting it in /usr/local/lib could harm other programs as well as 
breaking your intended client.  But putting that defective library in your
private directory isn't going to get you a working client either, 
nor would including it permanently in your executable as a static library.

	Ethan

Re: Progress on Mac installation cloning

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

On 3 March 2016 at 22:50,  <pl...@pi...> wrote:
>
> Firstly there are two ways to get PNG et co. : the older gdlib which you
> probably don't need to use now ; and whatever is already on the system
> for png/jpeg etc which is certainly already part of a basic MacOSX system.

It is not.

I happen to have
   /usr/X11/lib/libpng.dylib
(which probably came with X11 and might be missing on the student's
computer), but jpeg, pango, cairo etc. are certainly missing.

>
> for example my linux system shows this as part of the output from
> ./configure :
>
>    libgd-based png, jpeg, and gif terminals: no (see config.log)
>    cairo-based pdf and png terminals: yes
>
> What I think you are missing are the header files which are probably not
> installed by default. The configure script is looking for headers (
> sometimes the package has -devel added to the name )  , I'm not sure of
> the conventions for Mac packages.
>
> You probably need to install cairo and pango headers.

If he wants to use pango and cairo, he has to install them manually
from source. There are no -devel packages to be found anywhere (except
in third-party package managers that he wants to avoid). In the same
way he has to compile libpng, libjpeg and others from source.

> The 32b , 64b issue is something else. As I previously said you are
> trying to cross-compile here which means you will at least need the
> TARGET system header files available to the configure script.

No, he can use the same header files (and even the same libraries if
he sets the CFLAGS/CXXFLAGS properly), but that's beyond the scope of
this discussion.

> I suggest you master the first part and worry about that later.

Indeed. (I wouldn't even bother making 32-bit binaries at all.)

Mojca

Re: Progress on Mac installation cloning

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

On 3 March 2016 at 23:36, Thomas Mattison wrote:
> Where/how can I find a list of dependencies that could be
> statically linked into the gnuplot binary on the build machine,
> so I wouldn't have to distribute the libraries?

I'm not sure about X11 (MacPorts ships its own X11, but you probably
don't want to go there). I'm almost sure that you won't be able to
statically link AquaTerm.app, but apart from that I guess that all
other libraries could be statically linked.

The list of dependencies can get arbitrary long. Here's what we use in MacPorts.

Build dependency: pkg-config

Other dependencies: AquaTerm, cairo, expat, fontconfig, gd2, jpeg,
libcaca, libcerf, libiconv, libpng, lua, ncurses, pango, pdflib, Qt (4
or 5), readline, wxWidgets 3.0, zlib,

Not all of them are important, but pango, cairo (and either wxWidgets
or Qt) are very useful.

> Where/when do I do the --enable-static and --disable-shared ?
> When building gnuplot?  When (re-)building the libraries?

When building libraries. Some libraries would be dynamically link if a
dylib file exists, so often you need to make sure that only a static
library exists.

You should run
    otool -L /path/to/gnuplot
(probably "otool -L /usr/bin/gnuplot" in your case, but you can
already run it before you install it)
which will give you the list of dynamic libraries that need to exist
on the target system as well.

> I'm not sure what you are recommending for cases where
> I can't do a static link.

I believe that only AquaTerm would be such a case. Users have to
install it separately on their machines. Actually you could also build
AquaTerm and ship it with the rest. AquaTerm has two components: the
framework and the app. The framework could happily live in
/opt/gnuplot if needed. The AquaTerm.app would have to to
/Applications or somewhere else where "open -a AquaTerm" will work.

> Are you saying that I should make an /opt/gnuplot directory
> on the build machine, put the required dynamic libraries there,
> and tell the gnuplot build that the libraries are in /opt/gnuplot?

Yes, that would be much better than installing dynamic libraries into /usr/local

> How would I do that?

When building the libraries you run "./configure
--prefix=/opt/gnuplot". When building other libraries and gnuplot, you
need things like
    --with-gd=/opt/gnuplot
but you need to double-check for every library separately (./configure --help).

> Then in addition to the rsync of the tree that comes out of
> the gnuplot "make DESTDIR=/tmp/gnuplot install" , I would also
> presumably need to copy the /opt/gnuplot directory onto the
> destination machine.

Actually, if you install everything to /opt/gnuplot, you could just as
well copy the complete /opt/gnuplot (I assume you would only have
gnuplot dependencies there anyway). Maybe you could remove some stuff
from that folder, but I'm not sure which parts you could safely remove
and which ones not.

> And your point is that the dynamic libraries in /opt/gnuplot
> are less likely to get clobbered than if they are in their
> "standard" places?

Yes.

Gnuplot binary alone is in fact not problematic at all, but as soon as
you start shipping some libraries (like libpng.dylib inside
/usr/local/lib/libpng.dylib if you wouldn't build it statically for
some reason) this is just asking for problems later on. (Even if user
just decides to install MacPorts or HomeBrew later on, libpng.dylib in
/usr/local/lib will cause numerous headaches for that user and any bug
reports that the user would try to file would be immediately closed
with "please remove that library from /usr/local/lib".)

There is a chance that the Octave team has some building scripts.

Mojca

Re: Progress on Mac installation cloning

[Thomas M. <mat...@ph...>]

Where/how can I find a list of dependencies that could be 
statically linked into the gnuplot binary on the build machine, 
so I wouldn't have to distribute the libraries?

Where/when do I do the --enable-static and --disable-shared ?
When building gnuplot?  When (re-)building the libraries?

I'm not sure what you are recommending for cases where
I can't do a static link.  

Are you saying that I should make an /opt/gnuplot directory 
on the build machine, put the required dynamic libraries there, 
and tell the gnuplot build that the libraries are in /opt/gnuplot?

How would I do that?

Then in addition to the rsync of the tree that comes out of 
the gnuplot "make DESTDIR=/tmp/gnuplot install" , I would also
presumably need to copy the /opt/gnuplot directory onto the 
destination machine.  

And your point is that the dynamic libraries in /opt/gnuplot
are less likely to get clobbered than if they are in their
"standard" places?


On 2016-03-03, at 1:21 PM, Mojca Miklavec wrote:

> On 3 March 2016 at 21:56, Thomas Mattison wrote:
>> 
>> So the lesson is that Aquaterm needs to be on the build machine before the build.
> 
> Yes. You need all dependencies present on the machine where you build
> gnuplot (and all those dependencies have to be either included as
> static libraries or have to be present on the destination).
> 
>> Any idea what is going on, or advice?
> 
> I'm not sure how exactly you installed the libraries.
> 
> If you want to do this properly, you should better build all the
> dependencies yourself, ideally as static libraries. And you need to
> know which files exactly to copy to the destination machine (so that
> gnuplot keeps working). Again, do yourself and your students a favour
> and install the libraries to /opt/gnuplot rather than /usr/local.
> Please. You should set ./configure --prefix=/opt/gnuplot for every
> dependency. And probably something like --enable-static
> --disable-shared. Just make the final symlink from
> /usr/local/bin/gnuplot to /opt/gnuplot/bin/gnuplot. If you'll install
> things to /usr/local, students will sooner or later run into troubles.
> (Let's say that your colleague [or some other project that can be
> downloaded from web] comes to a similar idea and decides to offer
> students some other software compiled in the same way using a
> different version of one of the same libraries. Then gnuplot would
> stop working or start crashing if both scripts install to the same
> location.)
> 
> If you have your dynamic libraries installed at
>    /Users/mattison/anaconda/include/freetype2
> then gnuplot most likely won't work unless your students install the
> files to exactly the same location (or if you set up everything very
> very carefully and properly and run install_name_tool to change
> location of libraries).
> 
> Mojca



                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Error plotting lcdemo.dat

[Bastian M. <bma...@we...>]

When trying to plot "lcdemo.dat" using the current CVS version, I do get 
the following warning:

gnuplot> plot "lcdemo.dat"
               ^
          warning: Unrecognized 5 column plot style; resetting to 
boxerrorbars

Is that to be expected? Does anybody else see that?

   Bastian

Re: Progress on Mac installation cloning

[<pl...@pi...>]

On 03/03/16 20:56, Thomas Mattison wrote:
> Hi
>
> The goal is to make it easy for a non-computer-science student to install gnuplot
> on a reasonably modern Mac.  While it's free and not even very hard to install
> a compiler and package-manager on a Mac, I'm trying to avoid asking students
> to do that.  Instead, I want to build gnuplot on one Mac, and "clone" the
> installation on other Macs that don't have compiler and package manager.
>
> As I learned yesterday, the existing gnuplot makefile supports
> "make DESTDIR=/tmp/gnuplot install"
> That makes a tree starting at /tmp/gnuplot/usr
> I copied that tree to a flash drive as gnuplot64/usr
> I made a short script file to the gnuplot64 directory:
>
> #!/bin/sh
> echo "This script must be run from an account with administrative privileges"
> echo "You must enter the administrative user's password"
> sudo rsync -arv usr/* /usr
>
> The "sudo rsync" command copies everything to the place that "sudo make install" would have.
> (The script using "cp" that I mentioned yesterday doesn't work because "cp" on a Mac
> doesn't create the required directory structure, while "rsync" does.)
>
> I have tested this by building on a 10.6.8 Intel Core 2 Duo machine,
> and porting to a 10.10.5 Intel Core i7 machine via a flash drive.
> It worked at the level of "plot sin(x)" (I didn't do extensive regression testing).
> So the OS version doesn't have to match exactly.
>
> (Porting to a 10.6.8 Intel Core Duo machine doesn't work, giving an error
> "Bad CPU type in executable" presumably because the destination is 32 bits
> and the binary is 64 bits.  I haven't yet tried to do the build on a 32 bit
> machine to port to other 32 bit machines, but presumably that would work.)
>
> The build-machine had XQuartz (but not Aquaterm, at build time).
> The destination-machine didn't have XQuartz before the "rsync".
> I ran the native Terminal.app, and typed "gnuplot"
> It complained that X11 wasn't available, but I could still "set term dumb"
> and see something.
>
> When I installed XQuartz on the destination, I could type "gnuplot"
> into Terminal.app, and when I typed "plot sin(x)" it launched XQuartz
> and showed the plot.
>
> I could also start XQuartz first, which brings up an xterm window,
> and type "gnuplot" into that.
>
> Then I installed Aquaterm on the destination.  Aquaterm is much
> smaller than XQuartz, and I believe has native support for saving
> screen graphics as pdf files (gnuplot can of course do that too,
> but it requires several steps that students often get wrong).
>
> But the gnuplot installation would not accept "set term aqua"
>
> I then installed Aquaterm on the build-machine and ran
> ./configure --with-aquaterm    (also --with-readline=builtin in both cases).
> Doing "make" and "make install" then gave Aquaterm support on the build machine.
> (I haven't yet tested on the destination machine, I presume it will work).
>
> So the lesson is that Aquaterm needs to be on the build machine before the build.
>
> I want to make an even more capable version of gnuplot, so I'm following instructions from
> http://www.physics.buffalo.edu/phy410-505/tools/install/
> They say to install zlib, libpng, freetype, libgd, then build gnuplot.
> I expected that this would give access to the png, jpeg, and gif terminal types.
>
> The gnuplot ./configure step seemed to have a problem with libgd:
>    aqua terminal (OSX): yes
>    libgd-based png, jpeg, and gif terminals: no (see config.log)
>
>
> The gnuplot build gave an error:
>
> c++  -g -O2  -framework Foundation -framework AquaTerm -L/usr/X11/lib -o gnuplot alloc.o axis.o breaders.o boundary.o color.o command.o contour.o datablock.o datafile.o dynarray.o eval.o external.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o libcerf.o matrix.o misc.o mouse.o multiplot.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o     -lz -lgd -lgd -lz -liconv    -liconv
> Undefined symbols:
>    "_gdImagePng", referenced from:
>        _PNG_text in term.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[4]: *** [gnuplot] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> If I delete /user/local/bin/gnuplot then run "make install",
> it doesn't put an executable back.
>
> I'm building gnuplot 5.0.3 with zlib 1.2.8, libpng 1.6.21, freetype 2.4.10 and libgd 2.1.1 in place
> on Mac OS X 10.6.8 on Intel Core 2 Duo Mac Mini.
>
>
> Looking back at the libgd ./configure step, there seem to be some issues:
> checking for LIBPNG... no
> checking for LIBFREETYPE... no
> checking for LIBFONTCONFIG... no
> checking for jpeg_set_defaults in -ljpeg... no
> checking for LIBXPM... no
> checking for LIBVPX... no
> checking for LIBVPX... no
> checking for LIBTIFF... no
> checking for simple visibility declarations... yes
> checking whether pthreads work with -pthread... yes
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... -D_THREAD_SAFE
> checking for PTHREAD_PRIO_INHERIT... yes
> checking whether we are building for a Win32 host... no
>
> ** Configuration summary for libgd 2.1.1:
>
>     Support for Zlib:                 yes
>     Support for PNG library:          no
>     Support for JPEG library:         no
>     Support for VPX library:          no
>     Support for TIFF library:         no
>     Support for Freetype 2.x library: no
>     Support for Fontconfig library:   no
>     Support for Xpm library:          no
>     Support for pthreads:             yes
>
> There weren't any obvious actual build errors, but it looks like it won't do png or jpeg.
>
>
>
>
> I tried using gd 2.0.33 as stated on the http://www.physics.buffalo.edu/phy410-505/tools/install/
> link, rather than the more up to date libgd 2.1.1.   That gives a more promising .configure stage:
>
> ** Configuration summary for gd 2.0.33:
>
>     Support for PNG library:          yes
>     Support for JPEG library:         yes
>     Support for Freetype 2.x library: yes
>     Support for Fontconfig library:   yes
>     Support for Xpm library:          yes
>     Support for pthreads:             yes
>
>
> But, the "make" gives compile errors
>
>
>
> gcc -DHAVE_CONFIG_H -I. -I. -I. -I/Users/mattison/anaconda/include/freetype2 -g -O2 -MT gd_jpeg.lo -MD -MP -MF .deps/gd_jpeg.Tpo -c gd_jpeg.c  -fno-common -DPIC -o .libs/gd_jpeg.lo
> gd_jpeg.c:47:21: error: jpeglib.h: No such file or directory
> gd_jpeg.c:48:20: error: jerror.h: No such file or directory
> gd_jpeg.c:60: error: expected ')' before 'cinfo'
> gd_jpeg.c:112: error: expected ')' before 'cinfo'
> gd_jpeg.c: In function 'gdImageJpegCtx':
> gd_jpeg.c:116: error: storage size of 'cinfo' isn't known
> gd_jpeg.c:117: error: storage size of 'jerr' isn't known
> gd_jpeg.c:120: error: nested functions are disabled, use -fnested-functions to re-enable
> gd_jpeg.c:120: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'row'
> gd_jpeg.c:120: error: 'row' undeclared (first use in this function)
> gd_jpeg.c:120: error: (Each undeclared identifier is reported only once
> gd_jpeg.c:120: error: for each function it appears in.)
> gd_jpeg.c:121: error: 'JSAMPROW' undeclared (first use in this function)
> gd_jpeg.c:121: error: expected ';' before 'rowptr'
> gd_jpeg.c:123: error: 'JDIMENSION' undeclared (first use in this function)
> gd_jpeg.c:123: error: expected ';' before 'nlines'
> gd_jpeg.c:154: error: 'fatal_jpeg_error' undeclared (first use in this function)
> gd_jpeg.c:161: error: 'JCS_RGB' undeclared (first use in this function)
> gd_jpeg.c:164: error: 'TRUE' undeclared (first use in this function)
> gd_jpeg.c:178: error: expected ';' before 'gdCalloc'
> gd_jpeg.c:188: error: 'rowptr' undeclared (first use in this function)
> gd_jpeg.c:192: error: 'JPEG_LIB_VERSION' undeclared (first use in this function)
> gd_jpeg.c:198: error: 'JPEG_COM' undeclared (first use in this function)
> gd_jpeg.c:222: error: 'nlines' undeclared (first use in this function)
> gd_jpeg.c:250:2: error: #error IJG JPEG library BITS_IN_JSAMPLE value must be 8 or 12
> gd_jpeg.c: At top level:
> gd_jpeg.c:283: error: expected ')' before 'cinfo'
> gd_jpeg.c: In function 'gdImageCreateFromJpegCtx':
> gd_jpeg.c:293: error: storage size of 'cinfo' isn't known
> gd_jpeg.c:294: error: storage size of 'jerr' isn't known
> gd_jpeg.c:297: error: nested functions are disabled, use -fnested-functions to re-enable
> gd_jpeg.c:297: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'row'
> gd_jpeg.c:297: error: 'row' undeclared (first use in this function)
> gd_jpeg.c:299: error: 'JSAMPROW' undeclared (first use in this function)
> gd_jpeg.c:299: error: expected ';' before 'rowptr'
> gd_jpeg.c:301: error: 'JDIMENSION' undeclared (first use in this function)
> gd_jpeg.c:301: error: expected ';' before 'nrows'
> gd_jpeg.c:325: error: 'fatal_jpeg_error' undeclared (first use in this function)
> gd_jpeg.c:333: error: 'JPEG_APP0' undeclared (first use in this function)
> gd_jpeg.c:335: error: 'TRUE' undeclared (first use in this function)
> gd_jpeg.c:336: error: 'JPEG_HEADER_OK' undeclared (first use in this function)
> gd_jpeg.c:360: error: 'JCS_CMYK' undeclared (first use in this function)
> gd_jpeg.c:361: error: 'JCS_YCCK' undeclared (first use in this function)
> gd_jpeg.c:367: error: 'JCS_RGB' undeclared (first use in this function)
> gd_jpeg.c:444: error: 'jpeg_saved_marker_ptr' undeclared (first use in this function)
> gd_jpeg.c:444: error: expected ';' before 'marker'
> gd_jpeg.c:453: error: 'marker' undeclared (first use in this function)
> gd_jpeg.c:481: error: 'JSAMPLE' undeclared (first use in this function)
> gd_jpeg.c:488: error: 'rowptr' undeclared (first use in this function)
> gd_jpeg.c:493: error: nested functions are disabled, use -fnested-functions to re-enable
> gd_jpeg.c:493: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'currow'
> gd_jpeg.c:493: error: 'currow' undeclared (first use in this function)
> gd_jpeg.c:495: error: 'nrows' undeclared (first use in this function)
> gd_jpeg.c:514: error: nested functions are disabled, use -fnested-functions to re-enable
> gd_jpeg.c:514: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'currow'
> gd_jpeg.c: At top level:
> gd_jpeg.c:634: error: field 'pub' has incomplete type
> gd_jpeg.c:653: error: expected ')' before 'cinfo'
> gd_jpeg.c:700: error: expected ')' before 'cinfo'
> gd_jpeg.c:768: error: expected ')' before 'cinfo'
> gd_jpeg.c:810: error: expected ')' before 'cinfo'
> gd_jpeg.c:828: error: expected ')' before 'cinfo'
> gd_jpeg.c:866: error: field 'pub' has incomplete type
> gd_jpeg.c:882: error: expected ')' before 'cinfo'
> gd_jpeg.c:920: error: expected ')' before 'cinfo'
> gd_jpeg.c:945: error: expected ')' before 'cinfo'
> gd_jpeg.c:966: error: expected ')' before 'cinfo'
> make[2]: *** [gd_jpeg.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
>
> Any idea what is going on, or advice?
>
>
>
>                                        Cheers
>
> Prof. Thomas Mattison           Hennings 276
> University of British Columbia  Dept. of Physics and Astronomy
> 6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
> mat...@ph...         phone: 604-822-9690  fax:604-822-5324
>
>



You need to realise what ./configure is doing for you: it's quite a lot.

It is sniffing out what is already installed on the build system and 
adjusting the build  options to suite.

Firstly there are two ways to get PNG et co. : the older gdlib which you 
probably don't need to use now ; and whatever is already on the system 
for png/jpeg etc which is certainly already part of a basic MacOSX system.


for example my linux system shows this as part of the output from 
./configure :

   libgd-based png, jpeg, and gif terminals: no (see config.log)
   cairo-based pdf and png terminals: yes


What I think you are missing are the header files which are probably not 
installed by default. The configure script is looking for headers ( 
sometimes the package has -devel added to the name )  , I'm not sure of 
the conventions for Mac packages.

You probably need to install cairo and pango headers.

You should run ./configure --help and read through all the options : 
there are tons of them. This will let you force on ( or off ) the 
options you need. If something is missing it will complain, though not 
always in the most helpful way.


I seem to recall on problem you had was having install readline package: 
look at  using the following option:
   --with-readline=builtin


The 32b , 64b issue is something else. As I previously said you are 
trying to cross-compile here which means you will at least need the 
TARGET system header files available to the configure script. This means 
creating a parallel structure and pointing ./configure to it.

I suggest you master the first part and worry about that later.

regards, Peter.

Re: Progress on Mac installation cloning

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

On 3 March 2016 at 21:56, Thomas Mattison wrote:
>
> So the lesson is that Aquaterm needs to be on the build machine before the build.

Yes. You need all dependencies present on the machine where you build
gnuplot (and all those dependencies have to be either included as
static libraries or have to be present on the destination).

> Any idea what is going on, or advice?

I'm not sure how exactly you installed the libraries.

If you want to do this properly, you should better build all the
dependencies yourself, ideally as static libraries. And you need to
know which files exactly to copy to the destination machine (so that
gnuplot keeps working). Again, do yourself and your students a favour
and install the libraries to /opt/gnuplot rather than /usr/local.
Please. You should set ./configure --prefix=/opt/gnuplot for every
dependency. And probably something like --enable-static
--disable-shared. Just make the final symlink from
/usr/local/bin/gnuplot to /opt/gnuplot/bin/gnuplot. If you'll install
things to /usr/local, students will sooner or later run into troubles.
(Let's say that your colleague [or some other project that can be
downloaded from web] comes to a similar idea and decides to offer
students some other software compiled in the same way using a
different version of one of the same libraries. Then gnuplot would
stop working or start crashing if both scripts install to the same
location.)

If you have your dynamic libraries installed at
    /Users/mattison/anaconda/include/freetype2
then gnuplot most likely won't work unless your students install the
files to exactly the same location (or if you set up everything very
very carefully and properly and run install_name_tool to change
location of libraries).

Mojca

Progress on Mac installation cloning

[Thomas M. <mat...@ph...>]

Hi

The goal is to make it easy for a non-computer-science student to install gnuplot 
on a reasonably modern Mac.  While it's free and not even very hard to install 
a compiler and package-manager on a Mac, I'm trying to avoid asking students 
to do that.  Instead, I want to build gnuplot on one Mac, and "clone" the 
installation on other Macs that don't have compiler and package manager.

As I learned yesterday, the existing gnuplot makefile supports 
"make DESTDIR=/tmp/gnuplot install"
That makes a tree starting at /tmp/gnuplot/usr
I copied that tree to a flash drive as gnuplot64/usr
I made a short script file to the gnuplot64 directory:

#!/bin/sh
echo "This script must be run from an account with administrative privileges"
echo "You must enter the administrative user's password"
sudo rsync -arv usr/* /usr

The "sudo rsync" command copies everything to the place that "sudo make install" would have.
(The script using "cp" that I mentioned yesterday doesn't work because "cp" on a Mac
doesn't create the required directory structure, while "rsync" does.)

I have tested this by building on a 10.6.8 Intel Core 2 Duo machine,
and porting to a 10.10.5 Intel Core i7 machine via a flash drive.
It worked at the level of "plot sin(x)" (I didn't do extensive regression testing).
So the OS version doesn't have to match exactly.

(Porting to a 10.6.8 Intel Core Duo machine doesn't work, giving an error
"Bad CPU type in executable" presumably because the destination is 32 bits
and the binary is 64 bits.  I haven't yet tried to do the build on a 32 bit
machine to port to other 32 bit machines, but presumably that would work.)

The build-machine had XQuartz (but not Aquaterm, at build time).
The destination-machine didn't have XQuartz before the "rsync".
I ran the native Terminal.app, and typed "gnuplot"
It complained that X11 wasn't available, but I could still "set term dumb"
and see something.

When I installed XQuartz on the destination, I could type "gnuplot"
into Terminal.app, and when I typed "plot sin(x)" it launched XQuartz
and showed the plot.

I could also start XQuartz first, which brings up an xterm window,
and type "gnuplot" into that.

Then I installed Aquaterm on the destination.  Aquaterm is much
smaller than XQuartz, and I believe has native support for saving
screen graphics as pdf files (gnuplot can of course do that too, 
but it requires several steps that students often get wrong).

But the gnuplot installation would not accept "set term aqua"

I then installed Aquaterm on the build-machine and ran 
./configure --with-aquaterm    (also --with-readline=builtin in both cases).
Doing "make" and "make install" then gave Aquaterm support on the build machine.
(I haven't yet tested on the destination machine, I presume it will work).

So the lesson is that Aquaterm needs to be on the build machine before the build.

I want to make an even more capable version of gnuplot, so I'm following instructions from
http://www.physics.buffalo.edu/phy410-505/tools/install/
They say to install zlib, libpng, freetype, libgd, then build gnuplot.
I expected that this would give access to the png, jpeg, and gif terminal types.

The gnuplot ./configure step seemed to have a problem with libgd:
  aqua terminal (OSX): yes
  libgd-based png, jpeg, and gif terminals: no (see config.log) 


The gnuplot build gave an error:

c++  -g -O2  -framework Foundation -framework AquaTerm -L/usr/X11/lib -o gnuplot alloc.o axis.o breaders.o boundary.o color.o command.o contour.o datablock.o datafile.o dynarray.o eval.o external.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o libcerf.o matrix.o misc.o mouse.o multiplot.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o     -lz -lgd -lgd -lz -liconv    -liconv 
Undefined symbols:
  "_gdImagePng", referenced from:
      _PNG_text in term.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[4]: *** [gnuplot] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

If I delete /user/local/bin/gnuplot then run "make install",
it doesn't put an executable back.

I'm building gnuplot 5.0.3 with zlib 1.2.8, libpng 1.6.21, freetype 2.4.10 and libgd 2.1.1 in place
on Mac OS X 10.6.8 on Intel Core 2 Duo Mac Mini.


Looking back at the libgd ./configure step, there seem to be some issues:
checking for LIBPNG... no
checking for LIBFREETYPE... no
checking for LIBFONTCONFIG... no
checking for jpeg_set_defaults in -ljpeg... no
checking for LIBXPM... no
checking for LIBVPX... no
checking for LIBVPX... no
checking for LIBTIFF... no
checking for simple visibility declarations... yes
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking for PTHREAD_PRIO_INHERIT... yes
checking whether we are building for a Win32 host... no

** Configuration summary for libgd 2.1.1:

   Support for Zlib:                 yes
   Support for PNG library:          no
   Support for JPEG library:         no
   Support for VPX library:          no
   Support for TIFF library:         no
   Support for Freetype 2.x library: no
   Support for Fontconfig library:   no
   Support for Xpm library:          no
   Support for pthreads:             yes

There weren't any obvious actual build errors, but it looks like it won't do png or jpeg.




I tried using gd 2.0.33 as stated on the http://www.physics.buffalo.edu/phy410-505/tools/install/
link, rather than the more up to date libgd 2.1.1.   That gives a more promising .configure stage:

** Configuration summary for gd 2.0.33:

   Support for PNG library:          yes
   Support for JPEG library:         yes
   Support for Freetype 2.x library: yes
   Support for Fontconfig library:   yes
   Support for Xpm library:          yes
   Support for pthreads:             yes


But, the "make" gives compile errors



gcc -DHAVE_CONFIG_H -I. -I. -I. -I/Users/mattison/anaconda/include/freetype2 -g -O2 -MT gd_jpeg.lo -MD -MP -MF .deps/gd_jpeg.Tpo -c gd_jpeg.c  -fno-common -DPIC -o .libs/gd_jpeg.lo
gd_jpeg.c:47:21: error: jpeglib.h: No such file or directory
gd_jpeg.c:48:20: error: jerror.h: No such file or directory
gd_jpeg.c:60: error: expected ')' before 'cinfo'
gd_jpeg.c:112: error: expected ')' before 'cinfo'
gd_jpeg.c: In function 'gdImageJpegCtx':
gd_jpeg.c:116: error: storage size of 'cinfo' isn't known
gd_jpeg.c:117: error: storage size of 'jerr' isn't known
gd_jpeg.c:120: error: nested functions are disabled, use -fnested-functions to re-enable
gd_jpeg.c:120: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'row'
gd_jpeg.c:120: error: 'row' undeclared (first use in this function)
gd_jpeg.c:120: error: (Each undeclared identifier is reported only once
gd_jpeg.c:120: error: for each function it appears in.)
gd_jpeg.c:121: error: 'JSAMPROW' undeclared (first use in this function)
gd_jpeg.c:121: error: expected ';' before 'rowptr'
gd_jpeg.c:123: error: 'JDIMENSION' undeclared (first use in this function)
gd_jpeg.c:123: error: expected ';' before 'nlines'
gd_jpeg.c:154: error: 'fatal_jpeg_error' undeclared (first use in this function)
gd_jpeg.c:161: error: 'JCS_RGB' undeclared (first use in this function)
gd_jpeg.c:164: error: 'TRUE' undeclared (first use in this function)
gd_jpeg.c:178: error: expected ';' before 'gdCalloc'
gd_jpeg.c:188: error: 'rowptr' undeclared (first use in this function)
gd_jpeg.c:192: error: 'JPEG_LIB_VERSION' undeclared (first use in this function)
gd_jpeg.c:198: error: 'JPEG_COM' undeclared (first use in this function)
gd_jpeg.c:222: error: 'nlines' undeclared (first use in this function)
gd_jpeg.c:250:2: error: #error IJG JPEG library BITS_IN_JSAMPLE value must be 8 or 12
gd_jpeg.c: At top level:
gd_jpeg.c:283: error: expected ')' before 'cinfo'
gd_jpeg.c: In function 'gdImageCreateFromJpegCtx':
gd_jpeg.c:293: error: storage size of 'cinfo' isn't known
gd_jpeg.c:294: error: storage size of 'jerr' isn't known
gd_jpeg.c:297: error: nested functions are disabled, use -fnested-functions to re-enable
gd_jpeg.c:297: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'row'
gd_jpeg.c:297: error: 'row' undeclared (first use in this function)
gd_jpeg.c:299: error: 'JSAMPROW' undeclared (first use in this function)
gd_jpeg.c:299: error: expected ';' before 'rowptr'
gd_jpeg.c:301: error: 'JDIMENSION' undeclared (first use in this function)
gd_jpeg.c:301: error: expected ';' before 'nrows'
gd_jpeg.c:325: error: 'fatal_jpeg_error' undeclared (first use in this function)
gd_jpeg.c:333: error: 'JPEG_APP0' undeclared (first use in this function)
gd_jpeg.c:335: error: 'TRUE' undeclared (first use in this function)
gd_jpeg.c:336: error: 'JPEG_HEADER_OK' undeclared (first use in this function)
gd_jpeg.c:360: error: 'JCS_CMYK' undeclared (first use in this function)
gd_jpeg.c:361: error: 'JCS_YCCK' undeclared (first use in this function)
gd_jpeg.c:367: error: 'JCS_RGB' undeclared (first use in this function)
gd_jpeg.c:444: error: 'jpeg_saved_marker_ptr' undeclared (first use in this function)
gd_jpeg.c:444: error: expected ';' before 'marker'
gd_jpeg.c:453: error: 'marker' undeclared (first use in this function)
gd_jpeg.c:481: error: 'JSAMPLE' undeclared (first use in this function)
gd_jpeg.c:488: error: 'rowptr' undeclared (first use in this function)
gd_jpeg.c:493: error: nested functions are disabled, use -fnested-functions to re-enable
gd_jpeg.c:493: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'currow'
gd_jpeg.c:493: error: 'currow' undeclared (first use in this function)
gd_jpeg.c:495: error: 'nrows' undeclared (first use in this function)
gd_jpeg.c:514: error: nested functions are disabled, use -fnested-functions to re-enable
gd_jpeg.c:514: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'currow'
gd_jpeg.c: At top level:
gd_jpeg.c:634: error: field 'pub' has incomplete type
gd_jpeg.c:653: error: expected ')' before 'cinfo'
gd_jpeg.c:700: error: expected ')' before 'cinfo'
gd_jpeg.c:768: error: expected ')' before 'cinfo'
gd_jpeg.c:810: error: expected ')' before 'cinfo'
gd_jpeg.c:828: error: expected ')' before 'cinfo'
gd_jpeg.c:866: error: field 'pub' has incomplete type
gd_jpeg.c:882: error: expected ')' before 'cinfo'
gd_jpeg.c:920: error: expected ')' before 'cinfo'
gd_jpeg.c:945: error: expected ')' before 'cinfo'
gd_jpeg.c:966: error: expected ')' before 'cinfo'
make[2]: *** [gd_jpeg.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



Any idea what is going on, or advice?  



                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Re: Feature request: make clone

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

On 2 March 2016 at 23:22, Thomas Mattison wrote:
> Thanks Allin and Mojca for the quick answers!
>
> make DESTDIR=/tmp/gnuplot    did exactly what you said: made a small tree of stuff.
>
> I wrote a simple script:
>
> #!/bin/sh
> sudo cp -r usr/local/bin/*     /usr/local/bin
> sudo cp -r usr/local/libexec/* /usr/local/libexec
> sudo cp -r usr/local/share/*   /usr/local/share
> sudo cp -r usr/local/texlive/* /usr/local/texlive

Again ... if possible, try to install everything but the final binary
to a different prefix to avoid weird conflicts later on.

> I did the build on a Mac running 10.6.8, put the tree and the script on a flash drive, moved it to another Mac running 10.6.8, and ran the script.  It seems to have put things where I wanted, but when I tried running there, I got the error
>
> bash: /usr/local/bin/gnuplot: Bad CPU type in executable
>
> The build was done on a 2.4 GHz Intel Core 2 Duo machine, the destination was a 2 GHz Intel Core Duo.
> They are different CPU types.  So apparently more needs to match than just the OS version.

Oh, sorry, yes, you need a matching architecture as well. But there
are only two choices: i386, x86_64 (as well ass ppc and ppc64 with
some subvariants to be complete, but I hope you are not targeting
those).

Core 2 Duo will give you 64-bit binaries by default (I think) or
32-bit on request. Core Duo won't work with 64-bit at all.

The times of 32-bit processors are so far away that I completely
forgot about that problem (even if I'm currently thinking of buying a
PowerMac).

If you would want to target both in a single go, you could build with
"-arch i386 -arch x86_64", but that has to be done for all
dependencies as well and you'll end up with double size of the
binaries, so it's probably better to provide two separate variants
anyway. Or you could give 32-bit binaries to everyone. This should
work, but I wouldn't advise you to do that. (I would be a bit
surprised if your students still used 32-bit notebooks though. Apple
switched to 64-bit in 2006.)

> I thought that Macports etc still required students to install the compilers,
> which is what I'm trying to avoid.

All they have to do is fetch Xcode via App store. In case of HomeBrew
it might be sufficient to install just command line tools. Yes, they
need to do something, but it's not a rocket science and it is
certainly trivial compared to trying to build gnuplot by themselves.

But they get a big added value: they end up with a fully functional
package manager that they will be able to use for almost anything
else. If you teach them gnuplot, they might be interested to try
Octave next for example. Or who knows what.

> It's just hard for non-computer-science students to
> get their Macs configured to the point that they can do the build process.

Figuring out how to compile gnuplot was super hard for me as well (and
I needed a few years before I figured it out). I wouldn't advice
teaching students how to compile gnuplot, that would be way too
complicated for absolutely no added value.

But installing Xcode is just as easy as installing anything else.

> (Linux boxes have all the compiler and package manager and X-windows stuff by default).

No, not all of them do. I've seen some boxes without a compiler.
(Sure, all you need is to install the compiler with a trivial command
or with a sequence of mouse clicks.)

But if you show the students how easy it is to install the compiler
and a package manager, they might be grateful later on. If you give
them some files with soon-to-be-outdated gnuplot binaries, they'll
lose the binaries as soon as they upgrade the OS and will have no idea
where to get new ones.

Mojca

Re: Feature request: make clone

[Ethan A M. <sf...@us...>]

On Wednesday, 02 March, 2016 14:22:28 Thomas Mattison wrote:
> Thanks Allin and Mojca for the quick answers!
> 
> make DESTDIR=/tmp/gnuplot    did exactly what you said: made a small tree of stuff.
> 
> I wrote a simple script:
> 
> #!/bin/sh
> sudo cp -r usr/local/bin/*     /usr/local/bin
> sudo cp -r usr/local/libexec/* /usr/local/libexec
> sudo cp -r usr/local/share/*   /usr/local/share
> sudo cp -r usr/local/texlive/* /usr/local/texlive
> 
> I did the build on a Mac running 10.6.8, put the tree and the script on a flash drive, moved it to another Mac running 10.6.8, and ran the script.  It seems to have put things where I wanted, but when I tried running there, I got the error
> 
> bash: /usr/local/bin/gnuplot: Bad CPU type in executable
> 
> The build was done on a 2.4 GHz Intel Core 2 Duo machine, the destination was a 2 GHz Intel Core Duo.
> They are different CPU types.  So apparently more needs to match than just the OS version.

Core Duo is a 32-bit chip and can only run 32-bit executables.
Core 2 Duo is a 64-bit chip and you could use it to build and run
either a 32-bit or a 64-bit executable.
Clearly if your intent is to carry the resulting executable over
to a 32-bit machine, you need to build a 32-bit executable.

	Ethan



> 
> In any case, I've gotten as close to what I want as is reasonably, and unreasonably quickly!
> 
> 
> 
> 
> On 2016-03-02, at 1:43 PM, Mojca Miklavec wrote:
> 
> > On 2 March 2016 at 20:49, Thomas Mattison wrote:
> >> 
> >> The motivation for this is mostly for installing gnuplot on Mac's of non-computer-science students.  Only one person (like an instructor) would need to download the compiler, download the gnuplot source, build the executables, and create the clone-directory.  Everyone else would just copy the clone-directory and run the script inside.
> >> 
> >> I realize this would not necessarily work if the student Mac is running a different system version from the instructor.  It may be necessary to make a different clone-directory for each OS X system version.  But it would only be necessary to do ONCE per version, and not require EVERY student to install the compiler and do the build.
> >> 
> >> I also realize that students would still need to install Aquaterm and/or X11, but those have "real" installers so it's not such a big deal.
> > 
> > Allin already answered in the same way as I would.
> > 
> > I wanted to add that you usually only have to build a binary for the
> > oldest OS and that should automatically work on newer OS versions.
> > 
> > But what about using a package manager like MacPorts or Homebrew? You
> > would then get all the dependencies (including AquaTerm, X11, Qt, wxt,
> > pango, cairo, gd, ...) as well a all the updates automatically.
> 
> 
> I thought that Macports etc still required students to install the compilers,
> which is what I'm trying to avoid.
> 
> 
> > 
> > In any case I would advise you to try to install the headers and
> > libraries somewhere else than in /usr/local to avoid "messing up" the
> > system.
> > 
> > Mojca
> > 
> > PS: If someone would write a similar Qt- or wxt-based GUI as the one
> > for Windows (that is: an app that starts with a GUI rather than in a
> > terminal), I would volunteer to create a binary for OS X. The main
> > annoyance is packaging a binary for the terminal.
> 
> 
> I would be overjoyed with a Mac binary that just ran inside the default
> Terminal.app or an xterm window, with no extra GUI at all!  The functionality
> is fine as-is.  It's just hard for non-computer-science students to
> get their Macs configured to the point that they can do the build process.
> (Linux boxes have all the compiler and package manager and X-windows stuff by default).
> 
> 
> 
> 
>                                       Cheers
> 
> Prof. Thomas Mattison           Hennings 276
> University of British Columbia  Dept. of Physics and Astronomy
> 6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
> mat...@ph...         phone: 604-822-9690  fax:604-822-5324
> 
> 
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Feature request: make clone

[Thomas M. <mat...@ph...>]

Thanks Allin and Mojca for the quick answers!

make DESTDIR=/tmp/gnuplot    did exactly what you said: made a small tree of stuff.

I wrote a simple script:

#!/bin/sh
sudo cp -r usr/local/bin/*     /usr/local/bin
sudo cp -r usr/local/libexec/* /usr/local/libexec
sudo cp -r usr/local/share/*   /usr/local/share
sudo cp -r usr/local/texlive/* /usr/local/texlive

I did the build on a Mac running 10.6.8, put the tree and the script on a flash drive, moved it to another Mac running 10.6.8, and ran the script.  It seems to have put things where I wanted, but when I tried running there, I got the error

bash: /usr/local/bin/gnuplot: Bad CPU type in executable

The build was done on a 2.4 GHz Intel Core 2 Duo machine, the destination was a 2 GHz Intel Core Duo.
They are different CPU types.  So apparently more needs to match than just the OS version.

In any case, I've gotten as close to what I want as is reasonably, and unreasonably quickly!




On 2016-03-02, at 1:43 PM, Mojca Miklavec wrote:

> On 2 March 2016 at 20:49, Thomas Mattison wrote:
>> 
>> The motivation for this is mostly for installing gnuplot on Mac's of non-computer-science students.  Only one person (like an instructor) would need to download the compiler, download the gnuplot source, build the executables, and create the clone-directory.  Everyone else would just copy the clone-directory and run the script inside.
>> 
>> I realize this would not necessarily work if the student Mac is running a different system version from the instructor.  It may be necessary to make a different clone-directory for each OS X system version.  But it would only be necessary to do ONCE per version, and not require EVERY student to install the compiler and do the build.
>> 
>> I also realize that students would still need to install Aquaterm and/or X11, but those have "real" installers so it's not such a big deal.
> 
> Allin already answered in the same way as I would.
> 
> I wanted to add that you usually only have to build a binary for the
> oldest OS and that should automatically work on newer OS versions.
> 
> But what about using a package manager like MacPorts or Homebrew? You
> would then get all the dependencies (including AquaTerm, X11, Qt, wxt,
> pango, cairo, gd, ...) as well a all the updates automatically.


I thought that Macports etc still required students to install the compilers,
which is what I'm trying to avoid.


> 
> In any case I would advise you to try to install the headers and
> libraries somewhere else than in /usr/local to avoid "messing up" the
> system.
> 
> Mojca
> 
> PS: If someone would write a similar Qt- or wxt-based GUI as the one
> for Windows (that is: an app that starts with a GUI rather than in a
> terminal), I would volunteer to create a binary for OS X. The main
> annoyance is packaging a binary for the terminal.


I would be overjoyed with a Mac binary that just ran inside the default
Terminal.app or an xterm window, with no extra GUI at all!  The functionality
is fine as-is.  It's just hard for non-computer-science students to
get their Macs configured to the point that they can do the build process.
(Linux boxes have all the compiler and package manager and X-windows stuff by default).




                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Re: Feature request: make clone

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

On 2 March 2016 at 20:49, Thomas Mattison wrote:
>
> The motivation for this is mostly for installing gnuplot on Mac's of non-computer-science students.  Only one person (like an instructor) would need to download the compiler, download the gnuplot source, build the executables, and create the clone-directory.  Everyone else would just copy the clone-directory and run the script inside.
>
> I realize this would not necessarily work if the student Mac is running a different system version from the instructor.  It may be necessary to make a different clone-directory for each OS X system version.  But it would only be necessary to do ONCE per version, and not require EVERY student to install the compiler and do the build.
>
> I also realize that students would still need to install Aquaterm and/or X11, but those have "real" installers so it's not such a big deal.

Allin already answered in the same way as I would.

I wanted to add that you usually only have to build a binary for the
oldest OS and that should automatically work on newer OS versions.

But what about using a package manager like MacPorts or Homebrew? You
would then get all the dependencies (including AquaTerm, X11, Qt, wxt,
pango, cairo, gd, ...) as well a all the updates automatically.

In any case I would advise you to try to install the headers and
libraries somewhere else than in /usr/local to avoid "messing up" the
system.

Mojca

PS: If someone would write a similar Qt- or wxt-based GUI as the one
for Windows (that is: an app that starts with a GUI rather than in a
terminal), I would volunteer to create a binary for OS X. The main
annoyance is packaging a binary for the terminal.

Re: Feature request: make clone

[Allin C. <cot...@wf...>]

On Wed, 2 Mar 2016, Thomas Mattison wrote:

> Would it be possible to add a target to the makefile that will 
> create a directory containing copies of everything that "make 
> install" delivers, plus a short script that will do with the 
> contents of that directory what "make install" does?

If I'm understanding the request correctly, not only would it be 
possible, but it's already possible. You do, for example,

make DESTDIR=/tmp/gnuplot install

and under /tmp/gnuplot you find the entire tree that "make install" 
creates. You can probably see where to take things from there, in 
terms of packaging the result.

Allin Cottrell

Feature request: make clone

[Thomas M. <mat...@ph...>]

Hi

Would it be possible to add a target to the makefile that will create a directory containing copies of everything that "make install" delivers, plus a short script that will do with the contents of that directory what "make install" does?

The idea is that "make clone" would create a directory that could be copied to a different computer.  Then running the script in the directory on that computer would put the gnuplot components where they need to be, without the need to compile them.

The motivation for this is mostly for installing gnuplot on Mac's of non-computer-science students.  Only one person (like an instructor) would need to download the compiler, download the gnuplot source, build the executables, and create the clone-directory.  Everyone else would just copy the clone-directory and run the script inside.  

I realize this would not necessarily work if the student Mac is running a different system version from the instructor.  It may be necessary to make a different clone-directory for each OS X system version.  But it would only be necessary to do ONCE per version, and not require EVERY student to install the compiler and do the build.

I also realize that students would still need to install Aquaterm and/or X11, but those have "real" installers so it's not such a big deal.

The instructor might want other items in the clone-directory and the clone-script, like libgd, libpng, freetype, and zlib, but that could be done manually after "make clone" has done its thing.


                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

What was the intended difference between int_error(), os_error(), and graph_error()?

[sfeam <sf...@us...>]

This question comes from discussion of Bug #1741.

There are about 675 instances of calling int_error() in the gnuplot source code.
There are about 25 instances each of calls to os_error() or graph_error().
All three error paths do roughly the same thing except that graph_error() terminates
multiplot mode before proceeding.

Does anyone recall the original intent of having 3 different error paths?

Most of the os_error() call sites have to do with file handling, but there are many
other file errors that go through int_error().  If that was the intended distinction
it has been lost over several decades of development.

Bug #1741 points out that of the 3 error paths, only int_error() sets
GPVAL_ERRNO.  That obviously could be fixed, but the larger question
is whether there is any reason to keep the two little-used error paths at all?

	Ethan  

Re: Release of gnuplot version 5.0 Patchlevel 3

[Tatsuro M. <tma...@ya...>]

Hello

Windows binary packages (32 bit by Bastian and 64 bit by me)
are now available in 5.0.3 directory.

Enjoy gnuplotting


Tatsuro


----- Original Message -----
> From: sfeam 
> To: gnuplot-beta
> Cc: 
> Date: 2016/2/22, Mon 14:18
> Subject: Release of gnuplot version 5.0 Patchlevel 3
> 
> Announcing an incremental release Patchlevel 3 for gnuplot version 5.0
> ==========================================
> 
> Yes it has only been a month since the release of 5.0.2.
> In a bit of poor timing, four terminals received significant bug-fixes
> or upgrades just after that.
> 
> Patchlevel 3 (5.0.3) contains updates for four terminals
> 
>         wxt  - fixes for various font problems
>         qt   - plots are toggled only on left-click (other events ignored)
>         aqua - upgrade to support version 5 dash types
>         tkcanvas - huge rewrite to the 1999 era driver now supports v5
> 
> Patchlevel 3 also contains a back-port of image bookkeeping from the
> development version, which fixes bugs #1607 #1703 #1709
> There is also a fix for clipping bug #1614
> 
> Patchlevel 3 also includes some changes to the Windows build files that
> are only relevant if you are building Windows binaries from the source files.
> 
> Source files can be downloaded from SourceForge
> 
>       https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.3/
> 
> As always, pre-built 5.0.3 binaries for Windows are contributed by
> volunteers working from the released source and will appear when ready.
> Note that the testing versions in the "5.0 release candidates" folder 
> on
> SourceForge _do not_ include the final round of fixes present in the 
> source files.   Please be patient until the final 5.0.3 binaries can be 
> rebuilt and uploaded to the 5.0.3 distribution directory.
> 
>         happy gnuplotting,
> 
>             Ethan Merritt (sfeam) - gnuplot development team
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Release of gnuplot version 5.0 Patchlevel 3

[sfeam <sf...@us...>]

Announcing an incremental release Patchlevel 3 for gnuplot version 5.0
==========================================

Yes it has only been a month since the release of 5.0.2.
In a bit of poor timing, four terminals received significant bug-fixes
or upgrades just after that.

Patchlevel 3 (5.0.3) contains updates for four terminals

        wxt  - fixes for various font problems
        qt   - plots are toggled only on left-click (other events ignored)
        aqua - upgrade to support version 5 dash types
        tkcanvas - huge rewrite to the 1999 era driver now supports v5

Patchlevel 3 also contains a back-port of image bookkeeping from the
development version, which fixes bugs #1607 #1703 #1709
There is also a fix for clipping bug #1614

Patchlevel 3 also includes some changes to the Windows build files that
are only relevant if you are building Windows binaries from the source files.

Source files can be downloaded from SourceForge

      https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.3/

As always, pre-built 5.0.3 binaries for Windows are contributed by
volunteers working from the released source and will appear when ready.
Note that the testing versions in the "5.0 release candidates" folder on
SourceForge _do not_ include the final round of fixes present in the 
source files.   Please be patient until the final 5.0.3 binaries can be 
rebuilt and uploaded to the 5.0.3 distribution directory.

		happy gnuplotting,

			Ethan Merritt (sfeam) - gnuplot development team

Regression: plot with multiple for loops and variable definitions does not work

[Miquel G. <mi...@ic...>]

Hello,

The attached script works as expected when used with gnuplot-5.0.1 
but fails with gnuplot-5.0.2 and higher with the error 

  "test.g", line 13: undefined variable: for
  
Miquel