Menu
▾
▴
gnuplot-beta
|
From: m s. <mw...@us...> - 2007-01-28 23:07:10
|
> ----- Original Message -----
> From: "Timoth=E9e Lecomte" <tim...@en...>
> To: "Mike Sutton" <mw...@us...>
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Sun, 28 Jan 2007 22:58:40 +0100
> Hi Mike,
>=20
> The offending code in configure.in is:
>=20
> if test "$with_gd" !=3D no; then
> AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
> if test -n "$GDLIB_CONFIG"; then
> libgd_CPPFLAGS=3D`gdlib-config --cflags`
> libgd_LDFLAGS=3D`gdlib-config --ldflags`
> elif test -d "$with_gd"; then
> libgd_CPPFLAGS=3D"-I$with_gd/include"
> libgd_LDFLAGS=3D"-L$with_gd/lib"
> fi
> (...)
> fi
>=20
> So what you gave to --with-gd is only used if gdlib-config cannot=20
> be found in your $PATH. And then it doesn't even try to use the=20
> gdlib-config in the custom path that you provided, but just appends=20
> 'include' and 'libs' to it. This could indeed be improved.
OK. However, the expectation is that my --with specification would override
the default behavior. Perhaps, the test should be for $with_gd/bin/gdlib-c=
onfig
first, if fails then try in $PATH. I quickly tested the following and it
seems to work. (I'm not well versed in this configure script stuff but
I gave it a try).
if test -d "$with_gd"; then
if test -n "$with_gd/bin/gdlib-config"; then
libgd_CPPFLAGS=3D`$with_gd/bin/gdlib-config --cflags`
libgd_LDFLAGS=3D"-L$with_gd/lib "`$with_gd/bin/gdlib-config --ldflags`
else
libgd_CPPFLAGS=3D"-I$with_gd/include"
libgd_LDFLAGS=3D"-L$with_gd/lib"
fi
else
AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
if test -n "$GDLIB_CONFIG"; then
libgd_CPPFLAGS=3D`gdlib-config --cflags`
libgd_LDFLAGS=3D`gdlib-config --ldflags`
fi
fi
There still is the issue of testing for the fontconfig library.=20=20
There is not a unique function that can be tested for. I see
that gdlib-config can list the libraries it requires.
Mike Sutton
=3D
Mica Heli Guides, Canada
Private Canadian helicopter skiing. Powder skiing from our remote lodge nea=
r Jasper. Great prices, availability for this season. Guaranteed fresh deep=
powder every run. All tours private.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D1666da2f83f9115bd2aa1=
90b8f0b0899
|
|
From: m s. <mw...@us...> - 2007-01-29 04:38:01
Attachments:
configure.in.diff
|
OK. I think I have a working patch to configure.in to resolve the=20 --with-gd=3D issues. The same problem was also present in the=20 --with-pdf section. I was able to test the --with-gd stuff but not=20 the --with-pdf parts. However, the same basic logic is used in=20 both. Mike Sutton =3D Ruth's Chris Steak House Serious steak and fine wines. Easy online reservations. Book your table now. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Df68766c3b16c72099ff7c= 0eb075c04fd |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-01-29 05:18:33
|
I am not clear on what problem you are trying to fix exactly. The version of libgd found during configuration does not have to be the same one used at runtime. For instance, I have been working with several libgd versions since I'be been trying to push fixes upstream to libgd.org. I have seen no version-compatibility problems when running against any libgd version from 2.0.29 to 2.0.34-cvs, all with the same gnuplot executable. [pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have GIF support. Is that the issue? Anyhow, even if you force ./configure to use some particular version when building gnuplot, at runtime it will still pick the libgd.so.2 provided by the system setup or by LD_LIBRARY_PATH. Wouldn't it be easier just to upgrade the system's libgd? Ethan On Sunday 28 January 2007 20:37, m sutton wrote: > OK. I think I have a working patch to configure.in to resolve the > --with-gd= issues. The same problem was also present in the > --with-pdf section. I was able to test the --with-gd stuff but not > the --with-pdf parts. However, the same basic logic is used in > both. > > Mike Sutton -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Lars H. <lhe...@us...> - 2007-01-29 09:41:16
|
> Anyhow, even if you force ./configure to use some particular version > when building gnuplot, at runtime it will still pick the libgd.so.2 > provided by the system setup or by LD_LIBRARY_PATH. Wouldn't it be > easier just to upgrade the system's libgd? All Mike needs to do is prepend the directory that contains his local gdlib-config to PATH (assuming the local location is the resulty of a make install, not just the compile dir). No patch necessary. |
|
From: <HBB...@t-...> - 2007-01-29 19:21:50
|
Ethan A Merritt wrote: > Anyhow, even if you force ./configure to use some particular version > when building gnuplot, at runtime it will still pick the libgd.so.2 > provided by the system setup or by LD_LIBRARY_PATH. Not necessarily. Shared libraries can be registered with an absolute path. The don't have to be searched via LD_LIBRARY_PATH or related means, and the executable can influence its own effective search path to some extend. Viz. 'ld' options -R, -rpath etc. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-01-29 19:50:17
|
On Monday 29 January 2007 11:24, Hans-Bernhard Br=F6ker wrote: > Ethan A Merritt wrote: > > Anyhow, even if you force ./configure to use some particular version=20 > > when building gnuplot, at runtime it will still pick the libgd.so.2=20 > > provided by the system setup or by LD_LIBRARY_PATH. =20 >=20 > Not necessarily. Shared libraries can be registered with an absolute=20 > path. The don't have to be searched via LD_LIBRARY_PATH or related=20 > means, and the executable can influence its own effective search path to= =20 > some extend. Viz. 'ld' options -R, -rpath etc. That is true, at least on some systems. But so far as I know gnuplot's configure script doesn't do any such thing. =20 It may be that you can force this in the gdlib-config file; I don't know mu= ch=20 about that mechanism. But if I understand Lars' comment correctly,=20 the needed fix is not a change to the ./configure script but rather a change to the environmental variable PATH at the time ./configure is run. =20 |
|
From: m s. <mw...@us...> - 2007-01-30 01:50:44
|
> ----- Original Message ----- > From: "Ethan A Merritt" <merritt@u.washington.edu> > To: gnu...@li... > Subject: Re: User specified location of GD not carried into Makefiles > Date: Sun, 28 Jan 2007 21:18:17 -0800 >=20 >=20 > I am not clear on what problem you are trying to fix exactly. > The version of libgd found during configuration does not have to be > the same one used at runtime. For instance, I have been working with seve= ral > libgd versions since I'be been trying to push fixes upstream to libgd.org. > I have seen no version-compatibility problems when running against any > libgd version from 2.0.29 to 2.0.34-cvs, all with the same=20 > gnuplot executable. >=20 > [pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have > GIF support. Is that the issue? >=20 > Anyhow, even if you force ./configure to use some particular version > when building gnuplot, at runtime it will still pick the libgd.so.2 > provided by the system setup or by LD_LIBRARY_PATH. Wouldn't it be > easier just to upgrade the system's libgd? >=20 Let me try to explain this some more. I work on some systems that=20 are locked down. I cannot add packages as root. So this means I=20 have to build and install in my local home directory. Furthermore,=20 I often build only the static libraries for things like GD. This=20 removes the LD_LIBRARY_PATH issues and it is now easier to move the=20 executable to another host on our network. My reasoning is the configure script should examine a --with-gd=20 specified path before checking the $PATH. After all I just=20 explicitly told configure where to look. If the --with-gd path is=20 not respected then the wrong gd.h file will be included. As for the link time options to remember the path (-R, -rpath),=20=20 implementing this gets trickier because there is not a standard=20 option across all compilers. For now I would fore go trying to=20 implement this in the configure script. I hope that makes my rationale clearer. Mike Sutton =3D Low Cost Auto Insurance Paying Too Much for Auto Insurance? Get Lower Ohio Quotes Today. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D2c928adba226c84e2bc09= e9f322e81b3 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-01-30 03:21:54
|
On Monday 29 January 2007 17:50, m sutton wrote:
>
> Let me try to explain this some more. I work on some systems that
> are locked down. I cannot add packages as root. So this means I
> have to build and install in my local home directory. Furthermore,
> I often build only the static libraries for things like GD.
Will that even work?
libgd itself links to so many other libraries that a static build
seems at best cumbersome, and at worst incompatible. In particular
I would worry about dragging in a static version of libX11.
lascaux [806] ldd /home/local/lib/libgd.so.2.0.33
linux-gate.so.1 => (0xffffe000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0xb7f80000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7eb4000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7e94000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7e64000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7dfb000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7dd5000)
libz.so.1 => /lib/libz.so.1 (0xb7dc1000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7d9c000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c6e000)
libdl.so.2 => /lib/libdl.so.2 (0xb7c6a000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7c4a000)
/lib/ld-linux.so.2 (0x80000000)
> My reasoning is the configure script should examine a --with-gd
> specified path before checking the $PATH. After all I just
> explicitly told configure where to look. If the --with-gd path is
> not respected then the wrong gd.h file will be included.
See previous comments.
This should not matter, as gd.h is not significantly version-dependent.
> As for the link time options to remember the path (-R, -rpath),
> implementing this gets trickier because there is not a standard
Yes, I agree. The -rpath mechanism is not widely used.
> I hope that makes my rationale clearer.
Gnuplot's ./configure mechanism was not designed for cross-compilation
or for building an executable for running in a totally different
environment. I think you are expecting too much of it.
If I were you, I would just tweak src/Makefile after running
./configure. You can add include and link paths as you please.
If you are already prepared to fiddle the compile flags to create a
static executable, the rest of the tweaking seems relatively minor.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: <HBB...@t-...> - 2007-01-31 19:48:34
|
m sutton wrote: > My reasoning is the configure script should examine a --with-gd > specified path before checking the $PATH. ... except that --with-gd was invented long before gdlib-config, which is a way better solution to the underlying problem than any autoconf-fu we could come up with ourselves. Just use it. > After all I just > explicitly told configure where to look. You didn't tell it where to look for gdlib-config. The optional path argument of --with-gd specifies paths for the library, not gdlib-config. Ultimately, the mistake is to have installed libgd in a place where gdlib-config did not end up on your PATH. Such installations are, by all practical means and purposes, unusable. |
|
From: m s. <mw...@us...> - 2007-01-31 02:56:55
|
> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "m sutton" <mw...@us...>
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Mon, 29 Jan 2007 19:21:52 -0800
>=20
>=20
> On Monday 29 January 2007 17:50, m sutton wrote:
> >
> > Let me try to explain this some more. I work on some systems=20
> > that are locked down. I cannot add packages as root. So this=20
> > means I have to build and install in my local home directory.=20=20
> > Furthermore, I often build only the static libraries for things=20
> > like GD.
>=20
> Will that even work?
> libgd itself links to so many other libraries that a static build
> seems at best cumbersome, and at worst incompatible. In particular
> I would worry about dragging in a static version of libX11.
Works just fine. Here is what is in my local lib directory
>~/tmp/gnu/lib.171 %ls
libfreetype.a libgd.a libpng12.a libpng.a pkgconfig
libfreetype.la libgd.la libpng12.la libpng.la
My Gnuplot configure
./configure --with-gd=3D/home/mike/tmp/gnu
After configuring (modified version) and making here is dependencies of the=
final executable.
>~/tmp/gnuplot_cvs3/src.23 %ldd gnuplot
linux-gate.so.1 =3D> (0xffffe000)
libz.so.1 =3D> /lib/libz.so.1 (0x40025000)
libXpm.so.4 =3D> /usr/X11R6/lib/libXpm.so.4 (0x40036000)
libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x40046000)
libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x40111000)
libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x40130000)
libm.so.6 =3D> /lib/tls/libm.so.6 (0x4015c000)
libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x4017f000)
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40251000)
libc.so.6 =3D> /lib/tls/libc.so.6 (0x4025a000)
libdl.so.2 =3D> /lib/libdl.so.2 (0x40379000)
libexpat.so.0 =3D> /usr/lib/libexpat.so.0 (0x403e9000)
/lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
Notice that libgd and libpng do not appear in the shared object list. The =
linker finds only static libraries. This means that there is no dependency=
on those share libraries.
> > My reasoning is the configure script should examine a --with-gd=20
> > specified path before checking the $PATH. After all I just=20
> > explicitly told configure where to look. If the --with-gd path=20
> > is not respected then the wrong gd.h file will be included.
>=20
> See previous comments.
> This should not matter, as gd.h is not significantly version-dependent.
GIF animation is a recent addition and could be overlooked if the wrong gd.=
h is used.
> Gnuplot's ./configure mechanism was not designed for cross-compilation
> or for building an executable for running in a totally different
> environment. I think you are expecting too much of it.
I'm not cross-compiling. We have a few stand-alone RedHat clusters (4 clus=
ters 10 hosts each) all basically configured the same. If I use static PNG=
and GD libraries we can run the executable on any cluster/host without hav=
ing to fuss around with each user's LD_LIBRARY_PATH.
I'm just trying to improve configure's capability.
Mike Sutton
=3D
Christian Singles
Free Christian Personals Online. ""View Photos, Chat, Email & More."".
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3De0d0ab51515a7fd87d3a4=
e150c412ad5
|
|
From: m s. <mw...@us...> - 2007-01-31 02:56:57
|
I'll try another approach to explaining what is broken with configure. I'm=
going use GD as the example case.
The configure help states the following:
--with-gd=3DDIR where to find Tom Boutell's gd library
This leads me to understand that a directory [DIR] can be specified. Howev=
er, examining the actual configure.in file reveals that the specified direc=
tory is never used when a version of GD is found in $PATH. From configure.=
in
> if test "$with_gd" !=3D no; then
> AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
> if test -n "$GDLIB_CONFIG"; then
> libgd_CPPFLAGS=3D`gdlib-config --cflags`
> libgd_LDFLAGS=3D`gdlib-config --ldflags`
> elif test -d "$with_gd"; then
> libgd_CPPFLAGS=3D"-I$with_gd/include"
> libgd_LDFLAGS=3D"-L$with_gd/lib"
> fi
As you can see the first test is to try and find gdlib-config in $PATH. Th=
e elif branch checks the user specfied directory if and only if there is no=
other version of GD found in $PATH. This means that configure ignored my =
request to use a particular location for the GD library.
I spent some time examining the GD configure script since it can include a =
wide variety of external libraries. I found that GD does not properly loca=
te libpng when specified via --with-png. However, --with-freetype does wor=
k properly.
So here is the patch to configure.in that I propose. It will check the use=
r specified path first, then check $PATH. Here is the result of my change =
followed by a diff.
if test "$with_gd" !=3D no; then
if test -d "$with_gd"; then
if test -x "$with_gd/bin/gdlib-config"; then
GDLIB_CONFIG=3D"$with_gd/bin/gdlib-config"
else
libgd_CPPFLAGS=3D"-I$with_gd/include"
libgd_LDFLAGS=3D"-L$with_gd/lib"
fi
else
AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
fi
if test -n "$GDLIB_CONFIG"; then
libgd_CPPFLAGS=3D`$GDLIB_CONFIG --cflags`
if test "$with_gd" =3D yes; then
libgd_LDFLAGS=3D`$GDLIB_CONFIG --ldflags`
else
libgd_LDFLAGS=3D"-L"`$GDLIB_CONFIG --libdir`" "`$GDLIB_CONFIG --ldfla=
gs`
fi
fi
diff -u -u -r1.213 configure.in
--- configure.in 24 Jan 2007 05:22:11 -0000 1.213
+++ configure.in 29 Jan 2007 04:36:21 -0000
@@ -401,15 +401,24 @@
with_gd=3Dyes)
=20
if test "$with_gd" !=3D no; then
- AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
+ if test -d "$with_gd"; then
+ if test -x "$with_gd/bin/gdlib-config"; then
+ GDLIB_CONFIG=3D"$with_gd/bin/gdlib-config"
+ else
+ libgd_CPPFLAGS=3D"-I$with_gd/include"
+ libgd_LDFLAGS=3D"-L$with_gd/lib"
+ fi
+ else
+ AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
+ fi
if test -n "$GDLIB_CONFIG"; then
- libgd_CPPFLAGS=3D`gdlib-config --cflags`
- libgd_LDFLAGS=3D`gdlib-config --ldflags`
- elif test -d "$with_gd"; then
- libgd_CPPFLAGS=3D"-I$with_gd/include"
- libgd_LDFLAGS=3D"-L$with_gd/lib"
+ libgd_CPPFLAGS=3D`$GDLIB_CONFIG --cflags`
+ if test "$with_gd" =3D yes; then
+ libgd_LDFLAGS=3D`$GDLIB_CONFIG --ldflags`
+ else
+ libgd_LDFLAGS=3D"-L"`$GDLIB_CONFIG --libdir`" "`$GDLIB_CONFIG --ldfl=
ags`
+ fi
fi
-
_cppflags=3D"$CPPFLAGS"
_ldflags=3D"$LDFLAGS"
CPPFLAGS=3D"$CPPFLAGS $libgd_CPPFLAGS"
@@ -461,7 +470,7 @@
])
=20
if test -n "$GDLIB_CONFIG"; then
- libgd_LIBS=3D`gdlib-config --libs`
+ libgd_LIBS=3D`$GDLIB_CONFIG --libs`
fi
=20
dnl piece it all together
-----
Mike Sutton
=3D
Ship Authentic Maryland Crabcakes Online
CrabcakeFactoryUSA.com is a purveyor of authentic Maryland Crabcakes. Made =
by hand in our Ocean City, Maryland location since 1996. Jumbo all lump Mar=
yland Crabcakes.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Dc09333e12b3785217b22d=
b24988dbc30
|
