Progress on Mac installation cloning

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Progress on Mac installation cloning

Thomas Mattison-2
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
[hidden email]         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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Mojca Miklavec
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

------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Plotter-2
In reply to this post by Thomas Mattison-2
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
> [hidden email]         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.


------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Thomas Mattison-2
In reply to this post by Mojca Miklavec
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
[hidden email]         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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Mojca Miklavec
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

------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Mojca Miklavec
In reply to this post by Plotter-2
On 3 March 2016 at 22:50,  <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

sfeam
In reply to this post by Mojca Miklavec

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


------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Plotter-2
In reply to this post by Thomas Mattison-2
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
> [hidden email]         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.





------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Mojca Miklavec
In reply to this post by sfeam
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

------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Allin Cottrell
In reply to this post by Thomas Mattison-2
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



------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Allin Cottrell
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. [...]

I package the program that I work on, gretl, for OS X and the gretl
bundle includes gnuplot, so I thought it might be worth making a
gnuplot bundle by stripping out all the gretl stuff and revising the
metadata.

You can find the result at
http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

I don't suppose it will meet everyone's needs but here are the
specs:

* It's an x86_64 build, and will run on OS X 10.6.6 and higher.

* The gnuplot code is 5.1 (cvs) as of a few weeks ago.

* It's self-contained. No dependency on XQuartz. The only libraries
it requires from the OS are ones that are a standard part of the OS
X kit from Snow Leopard to El Capitan.

* Interactive terminals: wxt and aquaterm. Both are built into the
bundle; no need for a separate AquaTerm or wxWidgets installation.
The included wx is the native quartz version, so no GTK.

* All pango/cairo terminals included: pngcairo, pdfcairo, epscairo.
No Qt, no caca, no nonsense ;-)

* The installed size is about 22 MB, most of that made up by the
glib/pango/cairo stack and the wxWidgets libraries.

* To install, double-click on the pkg file. It's signed, so
GateKeeper shouldn't make a fuss. Installs into
/Applications/Gnuplot.app.

* After installation, you can launch gnuplot via its icon in
Applications; this opens an instance of Terminal with gnuplot
running in it.

* If you want to run gnuplot from the command-line directly, the
file to execute is

/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh

This is a shell script which sets up the environment then calls the
gnuplot binary. One could of course set up a shell alias.

Everything was built on Arch Linux using clang and friends.

Allin Cottrell

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Allin Cottrell
On Fri, 4 Mar 2016, Allin Cottrell wrote:

> I package the program that I work on, gretl, for OS X and the gretl bundle
> includes gnuplot, so I thought it might be worth making a gnuplot bundle by
> stripping out all the gretl stuff and revising the metadata.
>
> You can find the result at
> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

Sorry! That should be

http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg

Allin Cottrell

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Jun T.
In reply to this post by Allin Cottrell

2016/03/05 03:27, Allin Cottrell <[hidden email]> wrote:
> I package the program that I work on, gretl, for OS X and the gretl
> bundle includes gnuplot, so I thought it might be worth making a
> gnuplot bundle by stripping out all the gretl stuff and revising the
> metadata.

Great!

> You can find the result at
> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

Maybe http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg ?

... I've just got your next post which corrects the url.

> * After installation, you can launch gnuplot via its icon in
> Applications; this opens an instance of Terminal with gnuplot
> running in it.

This doesn't happen (OS X 10.9.5), but

> * If you want to run gnuplot from the command-line directly, the
> file to execute is
>
> /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh

this does works.
I've tested only aqua, wxt and pngcairo for a few plots, but guess
other terminals works as well.

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Allin Cottrell
On Sat, 5 Mar 2016, Jun T. wrote:

>
> 2016/03/05 03:27, Allin Cottrell <[hidden email]> wrote:
>> I package the program that I work on, gretl, for OS X and the gretl
>> bundle includes gnuplot, so I thought it might be worth making a
>> gnuplot bundle by stripping out all the gretl stuff and revising the
>> metadata.
>
> Great!
>
>> You can find the result at
>> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg
>
> Maybe http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg ?
>
> ... I've just got your next post which corrects the url.
>
>> * After installation, you can launch gnuplot via its icon in
>> Applications; this opens an instance of Terminal with gnuplot
>> running in it.
>
> This doesn't happen (OS X 10.9.5), but

Hmm. Clicking on the gnuplot icon in Applications should be about
equivalent to executing

/Applications/Gnuplot.app/Contents/MacOS/gnuplot.sh

from the command line. If you have time, could you try that and see
what's going wrong? Utilities/Console might also have something
relevant to say.

>> * If you want to run gnuplot from the command-line directly, the
>> file to execute is
>>
>> /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh
>
> this does works.
> I've tested only aqua, wxt and pngcairo for a few plots, but guess
> other terminals works as well.

Thanks for testing. Good to hear that at least those things work.

Allin Cottrell

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Mojca Miklavec
In reply to this post by Allin Cottrell
On 4 March 2016 at 19:27, Allin Cottrell wrote:
>
> I thought it might be worth making a
> gnuplot bundle by stripping out all the gretl stuff and revising the
> metadata.
>
> You can find the result at
> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg

Thanks a lot!

I kept fighting a lot trying to get something like that to work
properly without success.

I believe I now understand that it might have failed because gnuplot
didn't know what to do with -psn, but I forgot about that completely.
Thanks for demonstrating how to create an app bundle with Gnuplot.

Weird enough the installer refuses to work on 10.7 (I didn't try to
diagnose why), but the app works just fine.

(What about creating a dmg rather than pkg?)

> I don't suppose it will meet everyone's needs but here are the
> specs:
>
> * It's an x86_64 build, and will run on OS X 10.6.6 and higher.
>
> * The gnuplot code is 5.1 (cvs) as of a few weeks ago.
>
> * It's self-contained. No dependency on XQuartz. The only libraries
> it requires from the OS are ones that are a standard part of the OS
> X kit from Snow Leopard to El Capitan.
>
> * Interactive terminals: wxt and aquaterm. Both are built into the
> bundle; no need for a separate AquaTerm or wxWidgets installation.
> The included wx is the native quartz version, so no GTK.

Nice.

> Everything was built on Arch Linux using clang and friends.

Do you really want to say that you cross-compiled the binaries for OS
X on Linux?

Mojca

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Allin Cottrell
On Sat, 5 Mar 2016, Mojca Miklavec wrote:

> On 4 March 2016 at 19:27, Allin Cottrell wrote:
>>
>> I thought it might be worth making a gnuplot bundle by stripping
>> out all the gretl stuff and revising the metadata.
>>
>> You can find the result at
>> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg
>
> Thanks a lot!
>
> I kept fighting a lot trying to get something like that to work
> properly without success.
>
> I believe I now understand that it might have failed because gnuplot
> didn't know what to do with -psn, but I forgot about that completely.
> Thanks for demonstrating how to create an app bundle with Gnuplot.
>
> Weird enough the installer refuses to work on 10.7 (I didn't try to
> diagnose why), but the app works just fine.
>
> (What about creating a dmg rather than pkg?)

OK, good idea. Both Mojca and Thomas have given me evidence that the
Apple Package Installer program may be more conservative than I
thought, and may be blocking installation of my pkg file on Macs
where it should actually run OK. So here's a DMG version:

http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.dmg

The drill to install is: double-click to mount the disk image, then
drag from Gnuplot to Applications. This bypasses the official
installer. (Again, though, it's not going to work on anything other
than 10.6.6 or higher, 64-bit.)

>> I don't suppose it will meet everyone's needs but here are the
>> specs:
>>
>> * It's an x86_64 build, and will run on OS X 10.6.6 and higher.
>>
>> * The gnuplot code is 5.1 (cvs) as of a few weeks ago.
>>
>> * It's self-contained. No dependency on XQuartz. The only libraries
>> it requires from the OS are ones that are a standard part of the OS
>> X kit from Snow Leopard to El Capitan.
>>
>> * Interactive terminals: wxt and aquaterm. Both are built into the
>> bundle; no need for a separate AquaTerm or wxWidgets installation.
>> The included wx is the native quartz version, so no GTK.
>
> Nice.
>
>> Everything was built on Arch Linux using clang and friends.
>
> Do you really want to say that you cross-compiled the binaries for
> OS X on Linux?

Yes, indeed; clang is very nice that way, helped along by bomutils
(packaging) and openssl (signing). You need to install the
appropriate Apple SDK (I'm using 10.6) but that's fairly
straightforward.

Allin Cottrell

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Progress on Mac installation cloning

Jun T.
In reply to this post by Allin Cottrell

On Mar 5, 2016, at 05:08, Allin Cottrell <[hidden email]> wrote:

> On Sat, 5 Mar 2016, Jun T. wrote:
>>> * After installation, you can launch gnuplot via its icon in
>>> Applications; this opens an instance of Terminal with gnuplot
>>> running in it.
>>
>> This doesn't happen (OS X 10.9.5), but
>
> Hmm. Clicking on the gnuplot icon in Applications should be about
> equivalent to executing
>
> /Applications/Gnuplot.app/Contents/MacOS/gnuplot.sh
>
> from the command line. If you have time, could you try that and see what's going wrong?

Never mind. It was due to my (multiple) non-standard settings.

# I will send a long detail personally, since it has nothing to do
# with gnuplot.
------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta