Re: More Mac cloning progress

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

On 04/03/16 19:43, Thomas Mattison wrote:
> Thanks everyone for all the help and suggestions.  Here's where I am.
>
> Building gnuplot from source on a 10.6.8 Mac with xcode 3.2.6 and
> command line tools produces a working version, but I don't want to require
> students to install xcode or compile from source.
>
> Doing "make DESTDIR=/tmp/gnuplot" produces a tree that can be put onto
> student machines with a simple script that just does a "sudo rsync ..."
> Students also need to install XQuartz, but that's easy enough.
>
> The bare gnuplot doesn't have png, gif, or pdf support.
>
> If my build machine has Aquaterm installed, the gnuplot build has aquaterm support.
> Aquaterm can save screen graphics as pdf files, and that's adequate pdf support for now.
> Students need to install Aquaterm, but that's also easy.
>
> To add png and gif support, I need the gd library.
> The gd library needs freetype and libpng, and libpng needs zlib.
>
> Richard Gonsalves at SUNY Buffalo teaches a Computational Physics course
> and posted instructions on building gnuplot from source with these libraries.
>
> http://www.physics.buffalo.edu/phy410-505/tools/install/
>
> My first attempt was with
> zlib-1.2.8 (rather than 1.2.7)
> libpng-1.6.21 (rather than 1.5.13)
> freetype-2.4.10 (same as instructions)
> libgd-2.1.1 (rather than gd-2.0.33)
>
> These steps ran, but with some errors.
> But the gnuplot build had errors and didn't produce an executable.
>
> So I tried again using libpng-1.5.26, and gd-2.0.33
>
> The zlib, libpng, and freetype builds ran without errors,
> but the gd-2.0.33 build didn't work properly.
>
> My build machine has Python from Anaconda, which has an
> incompatible version of freetype on it.  The gd-build
> was getting confused by that, so I deleted the files in
> question (after zipping the originals so I can restore them).
>
> Then the gd-build seemed to pick up the right freetype,
> and seemed to work OK.
>
> Then I did the gnuplot build, and I have png and gif terminals,
> as well as Aquaterm, X11, and postscript.  That's good enough for now.
>
> The recipe so far is
> zlib-1.2.8
> libpng-1.5.26
> freetype-2.4.10
> gd-2.0.33
> gnuplot-5.0.3
>
>
> I did a "make DESTDIR=/tmp/pkgname install" for zlib, libpng, freetype, gd-2.0.3
> as well as "sudo make install", so I have copies of what they put where.
>
> I know the rsync trick works for cloning gnuplot and and its components.
>
> The next step will be to also use rsync to clone the libraries into /usr/local/lib .
>
> Do I also need to add things to some dynamic library search list on the target machines?
>
> Can I skip the /usr/local/lib/pkgconfig stuff?
>
> Can I skip the /usr/local/include stuff?
>
> Can I skip the /usr/local/bin/XXX-config binaries?
>
> Can I skip the /usr/local/share/man stuff?
>
>
> Thanks again!
>
>


I would avoid moving stuff  /usr/local ,  especially and because of 
libpng. IIRC they change the headers for many of the library calls and 
rendered 1.5.x and 1.6.x totally incompatible. If you get a mix or other 
software build and linked to a different version you will find all sorts 
fo stuff just starts breaking and it will be a major headache.

Advanced package managers on Linux systems tend to take care of this 
kind of thing and ensure all software installed is consistent.  From 
others comments this is clearly not the case on MacOSX.  The LInux 
package managers  manage the dependency hell you are likely to encounter.

I remember the png change-over on my Gentoo box, I had to rebuild half 
the system !!

Fedora 23  currently has at least four different versions of libpng  ! 
  PNG devs really ought to give a bit more thought to how they design 
their interface so that they do not have to keep redefining it in an 
incompatible way with each release. Backwards comparability MATTERS.

Since OSX does not provide that level of version control for you I 
suggest you stick it all in one place and keep it there.  PNG is too 
central to too many different things I don't think you want to get into 
that mess.


Personally, I don't even use png terminal now, despite that being my 
usual image format . It is good but the inconsistencies from what I see 
on the screen made it more work that it was worth: different line 
widths, text extents, line colours ....  It was a headache.  Now I just 
copy to clipboard and paste into gimp to save.

Gimp is a sledgehammer to crack a walnut in that case but it does the 
job. That way I get exactly what I see when I'm working reproduced as a 
png file.

The historical terminal design of gnuplot was quite clever but it has 
some annoying compromises, such as not knowing what size text is going 
to come out and so text areas and positioning are always approximative.


BTW Gimp is good for creating gif animations if that  is something you 
need to do. You do not need to start with a gif since Gimp will take any 
input format. Their paradigm is "export as" then select whatever format 
you want.  If you want to simplify what you need to install / build / 
copy etc. that may be worth considering.

You need one good interactive terminal to do your work, then let a 
graphics package take care of whatever file format you or your students 
need as an end result.

I prefer wxt but qt is probably technically better/faster .  wxt is 
gnomey which is maccy , so this may be closer to your usual environment. 
  QT is windozey.


You said you had problems with cp.  Maybe look at cp -a   option . 
Nothing wrong with rsync though.


Since you don't need all the gnuplot terminals to get all the different 
formats, I'd be incline to reduce the dependency list to a minimum and 
use some gfx software to do the conversions.

That's the was i'd tackle it.

Peter.