More Mac cloning progress

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

More Mac cloning progress

Thomas Mattison-2
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!



                                      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



------------------------------------------------------------------------------
_______________________________________________
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: More Mac cloning progress

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








------------------------------------------------------------------------------
_______________________________________________
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: More Mac cloning progress

Mojca Miklavec
On 4 March 2016 at 21:44,  <[hidden email]> wrote:
>
> 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.

It's just that one doesn't come by default. One can still install a
third party package manager.

> The LInux
> package managers  manage the dependency hell you are likely to encounter.

To be fair, Linux would not be much different in this particular case.
Assume that one would want to provide a patched gnuplot binary to
students running linux. The fact that linux is great at managing
dependencies is actually useless in this case because the one
providing the binaries doesn't know whether the target machine has
wxWidgets 2.8 or 3.0 installed for example (the same problem for any
other dependency), so in order to be able to provide linux binaries,
one would either have to ship all the dependencies along with the
binary (not much different from what many are criticising about OS X)
or build one package per each version of each linux distribution that
should be supported.


What Allin provided is *the* solution that should be used to
distribute gnuplot for OS X. No libraries conflict with each other (it
doesn't clutter the user's system and cluttering the system won't
affect Gnuplot.app), it is super easy to handle and just works.

Thomas, if what Allin provided doesn't satisfy your needs for one
reason or another or if you want to be able to build it independently,
try to at last replicate what he did with a potentially different set
of libraries.

Mojca

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta