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