gnuplot-info

[Gnuplot-info] Difficulty getting wxWidgets to work

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

Hello,

I need help.  I've been tasked with building a version of gnuplot 4.2 
using wxWidgets and
gtk2.  I'm doing this on a SLES 9 system, so I downloaded many of the 
constituent
kits, built them along with gtk2 and wxWidgets and "successfully" linked 
a gnuplot executable.

I start gnuplot:

./gnuplot

Terminal type set to 'wxt'
gnuplot> plot x*x
Failed to initialize wxWidgets.
gnuplot>

Here is a list of kit versions that I'm using:

atk-1.18.0.tar.gz
cairo-1.4.2.tar.gz
gd-2.0.34.tar.gz
glib-2.12.11.tar.gz
gnuplot-4.2.0.tar.gz
gtk+-2.10.11.tar.gz
libpng-1.2.16.tar.gz
pango-1.16.1.tar.gz
wxWidgets-2.8.2.tar.gz
zlib-1.2.3.tar.gz

What can I do to diagnose the failure?  Is there a log somewhere I can 
view? 
Any help is much appreciated.

Thanks,

Ron

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

[<HBB...@t-...>]

R. D. Ross wrote:

> I need help.  I've been tasked with building a version of gnuplot 4.2
>  using wxWidgets and gtk2.  I'm doing this on a SLES 9 system, so I
> downloaded many of the constituent kits, built them along with gtk2
> and wxWidgets and "successfully" linked a gnuplot executable.

> I start gnuplot:
> 
> ./gnuplot

This way of starting gnuplot indicates potential trouble.

Better try use "make install" then just run

	gnuplot

(without the "./" to start it from the current working directory).

> What can I do to diagnose the failure?  Is there a log somewhere I
> can view? 

	ldd gnuplot

should be worth a look, to check for possible installation problems of 
one of those lots of shared libraries you installed immediately before 
building gnuplot...

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

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

Hello,

Thank you for responding.  I'll send the information you asked
about below, along with a few additional comments.=20

> -----Original Message-----
> From: Hans-Bernhard Br=F6ker [mailto:HBB...@t-...]=20
> Sent: Friday, April 06, 2007 12:45 PM
> To: R. D. Ross
> Cc: gnu...@li...
> Subject: Re: [Gnuplot-info] Difficulty getting wxWidgets to work
>=20
> R. D. Ross wrote:
>=20
> > I need help.  I've been tasked with building a version of=20
> gnuplot 4.2 =20
> > using wxWidgets and gtk2.  I'm doing this on a SLES 9 system, so I=20
> > downloaded many of the constituent kits, built them along with gtk2=20
> > and wxWidgets and "successfully" linked a gnuplot executable.
>=20
> > I start gnuplot:
> >=20
> > ./gnuplot
>=20
> This way of starting gnuplot indicates potential trouble.
>=20
> Better try use "make install" then just run
>=20
> 	gnuplot
>=20
> (without the "./" to start it from the current working directory).

I did a "make install" after the build was completed.  I'll mention
that I've had no problems in the past running ./gnuplot, but I went
ahead and ran it from the full path:

/tmp/external.rross/bin/gnuplot     (This is the install area)

The results were the same as before.  Also, the other terminal types
seem to be OK.  At least, when I did this, it worked.

set terminal x11
plot x*x             (parabola displayed in an X window)
splot x*x+y*y        (3-dimensional surface is displayed in X window)


>=20
> > What can I do to diagnose the failure?  Is there a log=20
> somewhere I can=20
> > view?
>=20
> 	ldd gnuplot
>=20
> should be worth a look, to check for possible installation=20
> problems of one of those lots of shared libraries you=20
> installed immediately before building gnuplot...

I have included these items below:

- The configure parameters that I used in the build
- The link line from the log
- The output from "ldd gnuplot"

A bit more information.  The system used to compile this was SLES9.  =
This is

because we want to build it on a least common denominator, and have it =
run
successfully on other systems, like SLES10, RHEL4, RHEL5, and others.  =
The
eventual intent is to link the gnuplot binary statically (with the =
exception
of a few things like libm, libc) and distribute it along with a product =
that
calls gnuplot.  You will see many of the libraries that I compiled and
linked
in the 'ldd gnuplot' list.  Eventually we want to produce ".a" files and =

statically link the whole thing.  But first, it needs to work!

Also, the compiler used was gcc 4.0.2.  The machine native compiler, gcc
3.3.3
is not being used.  That is why some of the libraries are in
/usr/local/lib64,
(gcc 4.0.2) vs. /usr/lib64 (native installed compiler)

This is the 64 bit version.  When this works, we will also do a build =
for 32
bit.

# configure parameters

  export TERMLIBS=3D"-Bstatic -lpng -lgd -lpng -lfontconfig -lfreetype =
-lexpat
\
                     -lwx_gtk2univ-2.8"
 =20
  usr_local=3D/usr/local/lib64
  PREFIX=3D/tmp/external.rross

  export PKG_CONFIG_PATH=3D$PREFIX/lib/pkgconfig
  export LD_RUN_PATH=3D:$PREFIX/lib:$usr_local:
  export LD_LIBRARY_PATH=3D$PREFIX/lib:$usr_local:

  ./configure --prefix=3D$PREFIX \
  --without-tutorial \
  --enable-static \
  --with-png=3D$PREFIX \
  --with-gd=3D$PREFIX \
  --enable-wxwidgets \
  --with-wx-config=3D$PREFIX/bin \
  --with-pic \
  --disable-shared \
  LDFLAGS=3D"-L$PREFIX/lib -L$usr_local" CPPFLAGS=3D-I$PREFIX/include

# Link line

g++  -g -O2
-I/tmp/external.rross/lib/wx/include/gtk2univ-ansi-release-static-2.8
-I/tmp/external.rross/include/wx-2.8 -D_FILE_OFFSET_BITS=3D64 =
-D_LARGE_FILES
-D_LARGEFILE_SOURCE=3D1 -D__WXUNIVERSAL__ -D__WXGTK__ -pthread
-DPNG_NO_MMX_CODE -I/tmp/external.rross/include/cairo
-I/tmp/external.rross/include/libpng12
-I/tmp/external.rross/include/pango-1.0
-I/tmp/external.rross/include/glib-2.0
-I/tmp/external.rross/lib/glib-2.0/include -I/usr/include/freetype2
-DPNG_NO_MMX_CODE -I/tmp/external.rross/include/gtk-2.0
-I/tmp/external.rross/lib/gtk-2.0/include
-I/tmp/external.rross/include/atk-1.0 =
-I/tmp/external.rross/include/cairo
-I/tmp/external.rross/include/pango-1.0
-I/tmp/external.rross/include/glib-2.0
-I/tmp/external.rross/lib/glib-2.0/include -I/usr/include/freetype2
-I/tmp/external.rross/include/libpng12    -L/tmp/external.rross/lib
-L/usr/local/lib64 -L/usr/lib64 -L/usr/X11R6/lib64 -o gnuplot  alloc.o
axis.o breaders.o bitmap.o color.o command.o contour.o datafile.o =
dynarray.o
eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o
history.o internal.o interpol.o matrix.o misc.o mouse.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 stdfn.o tables.o term.o time.o unset.o util.o util3d.o =
variable.o
version.o  gp_cairo.o wxt_gui.o -lreadline  -lncurses -Bstatic -lpng =
-lgd
-lpng -lfontconfig -lfreetype -lexpat -lwx_gtk2univ-2.8 -lz -lgd -lXpm =
-lX11
-ljpeg -lfreetype -lpng12 -lz -lm  -L/tmp/external.rross/lib -pthread
-L/usr/X11R6/lib64   /tmp/external.rross/lib/libwx_gtk2univ-2.8.a =
-pthread
-L/tmp/external.rross/lib -L/usr/X11R6/lib64 -L/usr/lib64 -lgtk-x11-2.0
-lgdk-x11-2.0 -lXrandr -lXrender -lXinerama -lXext -lX11 -latk-1.0
-lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 =
-lgmodule-2.0
-ldl -lfreetype -lfontconfig -lpng12 -lgthread-2.0 -lrt -lglib-2.0
-lXinerama -lXxf86vm -lSM -lpng -lz -ljpeg -ltiff -lz -ldl -lm
-L/tmp/external.rross/lib -L/usr/lib64 -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lfreetype -lfontconfig -lpng12 -lpango-1.0 -lm =
-lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0   -L/tmp/external.rross/lib =
-L/usr/X11R6/lib64
-L/usr/lib64 -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXrender -lXinerama
-lXext -lX11 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl =
-lglib-2.0
-lfreetype -lfontconfig -lpng12   -lm

# ldd list

rross@shona1:/tmp/external.rross/bin> ldd gnuplot
        libreadline.so.4 =3D> /lib64/libreadline.so.4 =
(0x0000002a9566d000)
        libncurses.so.5 =3D> /lib64/libncurses.so.5 (0x0000002a957a7000)
        libpng12.so.0 =3D> /tmp/external.rross/lib/libpng12.so.0
(0x0000002a95908000)
        libgd.so.2 =3D> /tmp/external.rross/lib/libgd.so.2
(0x0000002a95a2c000)
        libfontconfig.so.1 =3D> /usr/lib64/libfontconfig.so.1
(0x0000002a95b82000)
        libfreetype.so.6 =3D> /usr/lib64/libfreetype.so.6 =
(0x0000002a95cbb000)
        libexpat.so.0 =3D> /usr/lib64/libexpat.so.0 (0x0000002a95e44000)
        libXpm.so.4 =3D> /usr/X11R6/lib64/libXpm.so.4 =
(0x0000002a95f67000)
        libX11.so.6 =3D> /usr/X11R6/lib64/libX11.so.6 =
(0x0000002a96077000)
        libjpeg.so.62 =3D> /usr/lib64/libjpeg.so.62 (0x0000002a96287000)
        libgtk-x11-2.0.so.0 =3D> =
/tmp/external.rross/lib/libgtk-x11-2.0.so.0
(0x0000002a963a9000)
        libgdk-x11-2.0.so.0 =3D> =
/tmp/external.rross/lib/libgdk-x11-2.0.so.0
(0x0000002a9682d000)
        libXrandr.so.2 =3D> /usr/X11R6/lib64/libXrandr.so.2
(0x0000002a969c0000)
        libXrender.so.1 =3D> /usr/X11R6/lib64/libXrender.so.1
(0x0000002a96ac4000)
        libXext.so.6 =3D> /usr/X11R6/lib64/libXext.so.6 =
(0x0000002a96bcd000)
        libatk-1.0.so.0 =3D> /tmp/external.rross/lib/libatk-1.0.so.0
(0x0000002a96cde000)
        libgdk_pixbuf-2.0.so.0 =3D>
/tmp/external.rross/lib/libgdk_pixbuf-2.0.so.0
 (0x0000002a96dff000)
        libpangoft2-1.0.so.0 =3D> =
/tmp/external.rross/lib/libpangoft2-1.0.so.0
(0x0000002a96f16000)
        libpango-1.0.so.0 =3D> /tmp/external.rross/lib/libpango-1.0.so.0
(0x0000002a97045000)
        libm.so.6 =3D> /lib64/tls/libm.so.6 (0x0000002a9718a000)
        libgobject-2.0.so.0 =3D> =
/tmp/external.rross/lib/libgobject-2.0.so.0
(0x0000002a972e2000)
        libgmodule-2.0.so.0 =3D> =
/tmp/external.rross/lib/libgmodule-2.0.so.0
(0x0000002a97423000)
        libdl.so.2 =3D> /lib64/libdl.so.2 (0x0000002a97527000)
        libgthread-2.0.so.0 =3D> =
/tmp/external.rross/lib/libgthread-2.0.so.0
(0x0000002a9762a000)
        librt.so.1 =3D> /lib64/tls/librt.so.1 (0x0000002a9772e000)
        libglib-2.0.so.0 =3D> /tmp/external.rross/lib/libglib-2.0.so.0
(0x0000002a97837000)
        libSM.so.6 =3D> /usr/X11R6/lib64/libSM.so.6 (0x0000002a979d7000)
        libtiff.so.3 =3D> /usr/lib64/libtiff.so.3 (0x0000002a97ae1000)
        libpangocairo-1.0.so.0 =3D>
/tmp/external.rross/lib/libpangocairo-1.0.so.0
 (0x0000002a97c35000)
        libcairo.so.2 =3D> /tmp/external.rross/lib/libcairo.so.2
(0x0000002a97d3e000)
        libstdc++.so.6 =3D> /usr/local/lib64/libstdc++.so.6
(0x0000002a97eb6000)
        libgcc_s.so.1 =3D> /usr/local/lib64/libgcc_s.so.1 =
(0x0000002a980b3000)
        libpthread.so.0 =3D> /lib64/tls/libpthread.so.0 =
(0x0000002a981c0000)
        libc.so.6 =3D> /lib64/tls/libc.so.6 (0x0000002a982d4000)
        libz.so.1 =3D> /lib64/libz.so.1 (0x0000002a984fc000)
        /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
        libICE.so.6 =3D> /usr/X11R6/lib64/libICE.so.6 =
(0x0000002a98610000)

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

[<HBB...@t-...>]

R. D. Ross wrote:

> I did a "make install" after the build was completed.  I'll mention
> that I've had no problems in the past running ./gnuplot, but I went
> ahead and ran it from the full path:
> 
> /tmp/external.rross/bin/gnuplot     (This is the install area)

That's not expected to be any improvement over

	./gnuplot

As I said: it should be run without specifying a path, to get the 
version that's actually installed.  Just like this:

	gnuplot

> The results were the same as before.  Also, the other terminal types
> seem to be OK.  At least, when I did this, it worked.

This, unfortunately, is not conclusive proof the installation is correct 
-- the gnuplot_x11 found this way could still be from a different 
version of gnuplot, mainly if you used environment variables to override 
default installation locations before.

> eventual intent is to link the gnuplot binary statically (with the exception
> of a few things like libm, libc) and distribute it along with a product that
> calls gnuplot.

I doubt that to be a viable option, mainly for X11 and stuff built on 
top of it (including wxwidgets).  You don't want to statically link libX11.

> You will see many of the libraries that I compiled and
> linked in the 'ldd gnuplot' list.  Eventually we want to produce ".a" files and 
> statically link the whole thing.  But first, it needs to work!

Wrong way round, I'm afraid.  Getting it to work with dynamic linking 
has no particular relevance to getting to work with static linking.

> # configure parameters
> 
>   export TERMLIBS="-Bstatic -lpng -lgd -lpng -lfontconfig -lfreetype -lexpat
> \
>                      -lwx_gtk2univ-2.8"

That will not work as planned.  You have to use configure arguments to 
specify which libraries you want, possibly overriding the entire library 
search path. The configure script doesn't do anything with TERMLIBS, so 
the autoconf'ed results will usually not match TERMLIBS.

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

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

[<HBB...@t-...>]

R. D. Ross wrote:

> The problem with this is that I would pick up a pre-installed 
> gnuplot binary from /usr/local/bin/gnuplot.  

You could and probably should test such 'not-quite-installed' packages 
where 'make install' is only an intermediate step towards building an 
RPM or whatever, in a shell with a modified $PATH, or in a chroot 
environment.

> 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?  

Yes.  It should render modifying TERMLIBS completely pointless.

More to the point, TERMLIBS is eventually auto-generated from 
configure's findings.  I.e. unless you're out to do something spooky, 
there should be no need to change what configure put in there.  It's 
easier to work with configure than to fight it.

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

I don't really know --- I personally don't do wxWidgets.  You may want 
to re-route this issue to the developers' mailing list gnuplot-beta on 
this same server (but please subscribe first, or I'll have to manually 
approve each posting, which can take a while)