Re: [Gnuplot-info] Difficulty getting wxWidgets to work

[R. D. R. <rd...@sb...>]

As before, thanks very much for responding and sharing your thoughts.
Please see below.

Ron

> -----Original Message-----
> From: Hans-Bernhard Br=F6ker [mailto:HBB...@t-...]=20
> Sent: Monday, April 09, 2007 1:16 PM
> To: R. D. Ross
> Cc: 'R. D. Ross'; gnu...@li...
> Subject: Re: [Gnuplot-info] Difficulty getting wxWidgets to work
>=20
> R. D. Ross wrote:
>=20
> > I did a "make install" after the build was completed.  I'll mention=20
> > that I've had no problems in the past running ./gnuplot, but I went=20
> > ahead and ran it from the full path:
> >=20
> > /tmp/external.rross/bin/gnuplot     (This is the install area)
>=20
> That's not expected to be any improvement over
>=20
> 	./gnuplot
>=20
> As I said: it should be run without specifying a path, to get=20
> the version that's actually installed.  Just like this:
>=20
> 	gnuplot

The problem with this is that I would pick up a pre-installed=20
gnuplot binary from /usr/local/bin/gnuplot.  I explain below
why it is not a problem to specify the install path when
running gnuplot.

>=20
> > The results were the same as before.  Also, the other=20
> terminal types=20
> > seem to be OK.  At least, when I did this, it worked.
>=20
> This, unfortunately, is not conclusive proof the installation=20
> is correct

I believe I can show more conclusive proof below.

> -- the gnuplot_x11 found this way could still be from a=20
> different version of gnuplot, mainly if you used environment=20
> variables to override default installation locations before.

I believe not.  Here is the reason - when gnuplot is built, the
configure script is run with "--prefix=3D$PREFIX".  The path specified =
with=20
$PREFIX will determine these things:

o Where the package will be installed with "make install"

o The path will be compiled into the gnuplot binary so that it will
look at this path in order to find these resources:

  $PREFIX/libexec/gnuplot/4.2/gnuplot_x11
  $PREFIX/share/gnuplot/4.2/gnuplot.gih

As a demonstration, I'll move aside these directories and display the
results.

cd /tmp/external.rross

rross@shona1:/tmp/external.rross> ls
bin  etc  include  info  lib  libexec  man  share
rross@shona1:/tmp/external.rross> mv libexec libexec.sav
rross@shona1:/tmp/external.rross> mv share share.sav
rross@shona1:/tmp/external.rross> ls
bin  etc  include  info  lib  libexec.sav  man  share.sav

rross@shona1:/tmp/external.rross> /tmp/external.rross/bin/gnuplot

( much header info deleted)

Terminal type set to 'wxt'
gnuplot> set term x11
Terminal type set to 'x11'
Options are '0'
gnuplot> Expected X11 driver:
/tmp/external.rross/libexec/gnuplot/4.2/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

gnuplot> help term
/tmp/external.rross/share/gnuplot/4.2/gnuplot.gih: No such file or =
directory
gnuplot>=20


Notice above that the gnuplot binary requires that the supporting files =
be
under the "hardcoded" prefix directory, otherwise it will not find them.
This
is true regardless of where the binary is picked up from, so having it =
in a
PATH variable is not necessary.  If I mv the directories back to their
original
names, everything will work again.  You can try this for yourself if you =
are
unsure about it. =20

The point from all this is that the support files are tied to the =
gnuplot
binary, and there is no danger of other files being picked up by an
extraneous PATH variable setting.

Now, it is possible to override the gnuplot_x11, and gnuplot.gih files =
by
setting these environment variables:

GNUHELP
GNUPLOT_DRIVER_DIR

If one wants to relocate the gnuplot install area, these need to be set
in order to override the precompiled directory locations.  In fact, we
have written a short wrapper script which sets these variables, and then
invokes the gnuplot binary.  This is necessary when we deliver gnuplot
as part of a larger product.  We can't predict where the customer will
install the entire release, so it is necessary to make this relocation
ability available.

However, I am not using these variables when testing.


> > eventual intent is to link the gnuplot binary statically (with the=20
> > exception of a few things like libm, libc) and distribute it along=20
> > with a product that calls gnuplot.
>=20
> I doubt that to be a viable option, mainly for X11 and stuff=20
> built on top of it (including wxwidgets).  You don't want to=20
> statically link libX11.

This is a good point.  Thanks for bringing it to my attention.

> > You will see many of the libraries that I compiled and=20
> linked in the=20
> > 'ldd gnuplot' list.  Eventually we want to produce ".a" files and=20
> > statically link the whole thing.  But first, it needs to work!
>=20
> Wrong way round, I'm afraid.  Getting it to work with dynamic=20
> linking has no particular relevance to getting to work with=20
> static linking.

You may be right about that.  However, the present purpose is to
determine whether it will work at all.  So far it has not.  If we
can get it to work, further choices will be made.  If it does not
work, no further choices are possible.

>=20
> > # configure parameters
> >=20
> >   export TERMLIBS=3D"-Bstatic -lpng -lgd -lpng -lfontconfig=20
> -lfreetype=20
> > -lexpat \
> >                      -lwx_gtk2univ-2.8"
>=20
> That will not work as planned.  You have to use configure=20
> arguments to specify which libraries you want, possibly=20
> overriding the entire library search path. The configure=20
> script doesn't do anything with TERMLIBS, so the autoconf'ed=20
> results will usually not match TERMLIBS.

Fair enough on that.  I see from "configure --help" that many other env
variables will influence the configure script, but TERMLIBS isn't =
mentioned.
TERMLIBS here was intended to influence the "make" process though.  I =
guess
the pkg-config information should help with this? =20

In any case, thanks for responding.  As a general question, what is
recommended
to get wxWidgets to work with gtk2 when building gnuplot?  I'm open to =
any
suggestions.

Best wishes,

Ron


=20