building GD using a locally-installed libgd (old libgd also present on system)
building GD using a locally-installed libgd (old libgd also present on system)
am 10.11.2006 17:54:06 von jmg3000
I'm trying to build GD, but have it use a libgd (Boutell's C library)
that I built in my own ~/opt directory. The problem is, there's also an
older libgd installed on the system (2.0.9 I think), but I don't have
root access and so cannot remove this older version. I want GD to
eventually get installed into ~/perllib.
I've tried "perl Makefile.PL PREFIX=/home/me/perllib", but
unfortunately, it's finding the gd.h in /usr/include (the old one)
instead of /home/me/opt/include (the current one), and it's causing the
build to fail.
How can I get GD to build correctly using my own locally-installed
libgd on a system that also has an older libgd present?
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 10.11.2006 18:58:18 von Sisyphus
wrote in message
news:1163177646.658382.281090@h48g2000cwc.googlegroups.com.. .
> I'm trying to build GD, but have it use a libgd (Boutell's C library)
> that I built in my own ~/opt directory. The problem is, there's also an
> older libgd installed on the system (2.0.9 I think), but I don't have
> root access and so cannot remove this older version. I want GD to
> eventually get installed into ~/perllib.
>
> I've tried "perl Makefile.PL PREFIX=/home/me/perllib", but
> unfortunately, it's finding the gd.h in /usr/include (the old one)
> instead of /home/me/opt/include (the current one), and it's causing the
> build to fail.
>
> How can I get GD to build correctly using my own locally-installed
> libgd on a system that also has an older libgd present?
>
Probably easiest to just do some appropriate harcoding in the Makefile.PL.
(This is what I do on Win32, and it works for me.)
Find the'LIBS' and 'INC' entries in the WriteMakefile() section of said
Makefile.PL and change them to something like:
'LIBS' => [join(' ','/home/me/opt/lib',@LIBPATH,@LIBS)],
'INC' => join(' ','/home/me/opt/include',@INC),
Then just run 'make clean' and start over again - responding to all prompts
as usual.
You haven't told us where libgd is so I've had a guess that it's in
/home/me/opt/lib - which, of course, is not necessarily the case.
Cheers,
Rob
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 10.11.2006 21:04:45 von jmg3000
Sisyphus wrote:
> wrote in message
> [snip]
> >
> > How can I get GD to build correctly using my own locally-installed
> > libgd on a system that also has an older libgd present?
> >
>
> Probably easiest to just do some appropriate harcoding in the Makefile.PL.
> (This is what I do on Win32, and it works for me.)
>
> Find the'LIBS' and 'INC' entries in the WriteMakefile() section of said
> Makefile.PL and change them to something like:
>
> 'LIBS' => [join(' ','/home/me/opt/lib',@LIBPATH,@LIBS)],
> 'INC' => join(' ','/home/me/opt/include',@INC),
>
> Then just run 'make clean' and start over again - responding to all prompts
> as usual.
Hm. Seems like there ought to be an easier way...
> You haven't told us where libgd is so I've had a guess that it's in
> /home/me/opt/lib [snip]
Yup. That's the place.
Well, anyway, after changing those lines in Makefile.PL, creating the
makefile seems to still have issues:
=== snip ===
$ perl Makefile.PL PREFIX=/home/me/perllib
Configuring for libgd version 2.0.33.
Checking for stray libgd header files...
** WARNING: found gd.h header file in /usr/includegd.h, but it is
expected at /home/me/opt/include/gd.h. This may cause compile errors!
**
** WARNING: found gd.h header file in /usr/include/gd.h, but it is
expected at /home/me/opt/include/gd.h. This may cause compile errors!
**
** Possible problems found **
Included Features: GD_XPM GD_JPEG GD_FONTCONFIG GD_FREETYPE
GD_PNG GD_GIF GD_UNCLOSEDPOLY GD_ANIMGIF GD_FTCIRCLE VERSION_33
GD library used from: /home/me/opt
Checking if your kit is complete...
Looks good
Warning: prerequisite Math::Trig 0 not found.
Unrecognized argument in LIBS ignored: '/home/me/opt/lib'
Writing Makefile for GD
=== /snip ===
After that, I run make, and it seems to work fine:
=== snip ===
$ make
cp GD/Polyline.pm blib/lib/GD/Polyline.pm
cp qd.pl blib/lib/qd.pl
cp GD/Image.pm blib/lib/GD/Image.pm
cp GD/Simple.pm blib/lib/GD/Simple.pm
cp GD.pm blib/lib/GD.pm
AutoSplitting blib/lib/GD.pm (blib/lib/auto/GD)
cp GD/Polygon.pm blib/lib/GD/Polygon.pm
/usr/bin/perl5.8.0 /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap
/usr/lib/perl5/5.8.0/ExtUtils/typemap -typemap typemap GD.xs > GD.xsc
&& mv GD.xsc GD.c
cc -c /home/me/opt/include -I/home/me/opt/include -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\"2.35\"
-DXS_VERSION=\"2.35\" -fPIC "-I/usr/lib/perl5/5.8.0/i386-linux/CORE"
-DHAVE_JPEG -DHAVE_FT -DHAVE_XPM -DHAVE_GIF -DHAVE_PNG -DHAVE_ANIMGIF
-DVERSION_33 -DHAVE_UNCLOSEDPOLY -DHAVE_FONTCONFIG -DHAVE_FTCIRCLE GD.c
cc: /home/me/opt/include: linker input file unused because linking not
done
Running Mkbootstrap for GD ()
chmod 644 GD.bs
rm -f blib/arch/auto/GD/GD.so
LD_RUN_PATH="/usr/X11R6/lib:/usr/lib" cc -shared -L/usr/local/lib GD.o
-o blib/arch/auto/GD/GD.so -L/usr/lib -L/usr/X11R6/lib
-L/home/me/opt/lib -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12
-lz -lm -lgd
chmod 755 blib/arch/auto/GD/GD.so
cp GD.bs blib/arch/auto/GD/GD.bs
chmod 644 blib/arch/auto/GD/GD.bs
cp bdf_scripts/bdf2gdfont.pl blib/script/bdf2gdfont.pl
/usr/bin/perl5.8.0 "-MExtUtils::MY" -e "MY->fixin(shift)"
blib/script/bdf2gdfont.pl
Manifying blib/man3/GD::Polyline.3
Manifying blib/man1/bdf2gdfont.pl.1
Manifying blib/man3/GD::Image.3
Manifying blib/man3/GD.3
Manifying blib/man3/GD::Simple.3
Manifying blib/man3/GD::Polygon.3
=== /snip ===
But "make test" fails:
=== snip ===
$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl5.8.0 "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/GD..........Can't load './blib/arch/auto/GD/GD.so' for module GD:
../blib/arch/auto/GD/GD.so: undefined symbol: gdImageGifAnimAddPtr at
/usr/lib/perl5/5.8.0/i386-linux/DynaLoader.pm line 229.
at t/GD.t line 14
Compilation failed in require at t/GD.t line 14.
BEGIN failed--compilation aborted at t/GD.t line 14.
t/GD..........dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-12
Failed 12/12 tests, 0.00% okay
t/Polyline....Can't load
'/home/me/opt/src/perl_modules/GD-2.35/blib/arch/auto/GD/GD. so' for
module GD:
/home/me/opt/src/perl_modules/GD-2.35/blib/arch/auto/GD/GD.s o:
undefined symbol: gdImageGifAnimAddPtr at
/usr/lib/perl5/5.8.0/i386-linux/DynaLoader.pm line 229.
at /home/me/opt/src/perl_modules/GD-2.35/blib/lib/GD/Polyline.p m line
45
Compilation failed in require at
/home/me/opt/src/perl_modules/GD-2.35/blib/lib/GD/Polyline.p m line 45.
BEGIN failed--compilation aborted at
/home/me/opt/src/perl_modules/GD-2.35/blib/lib/GD/Polyline.p m line 45.
Compilation failed in require at t/Polyline.t line 10.
BEGIN failed--compilation aborted at t/Polyline.t line 10.
t/Polyline....dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------ -------------------
t/GD.t 255 65280 12 23 191.67% 1-12
t/Polyline.t 255 65280 1 2 200.00% 1
Failed 2/2 test scripts, 0.00% okay. 13/13 subtests failed, 0.00% okay.
make: *** [test_dynamic] Error 255
=== /snip ===
That ./blib/arch/auto/GD/GD.so does indeed exist. Line 14 of GD.t is:
"use GD qw(:DEFAULT GD_CMP_IMAGE);".
After that, "make install" seems to work fine.
For kicks, I tried out the demos anyway. I added "use lib
'/home/me/perllib';" and they wouldn't work. Then I tried "use lib
'/home/me/perllib/lib/perl5/site_perl/5.8.0/i386-linux';", and, to my
surprise, they worked. The sample cgi script also worked.
Why did "make test" fail?
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 10.11.2006 21:10:12 von jmg3000
jmg3...@gmail.com wrote:
> [snip]
>
> After that, "make install" seems to work fine.
>
> For kicks, I tried out the demos anyway. I added "use lib
> '/home/me/perllib';" and they wouldn't work. Then I tried "use lib
> '/home/me/perllib/lib/perl5/site_perl/5.8.0/i386-linux';", and, to my
> surprise, they worked. The sample cgi script also worked.
>
> Why did "make test" fail?
Hm. Also note:
~/opt/src/perl_modules/GD-2.35/blib/arch/auto/GD$ ldd ./GD.so
[snip]
libgd.so.2 => /usr/lib/libgd.so.2 (0x0030a000)
[snip]
So, it's not even using my new libgd.
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 11.11.2006 02:41:03 von Sisyphus
wrote in message
news:1163189085.570476.64880@e3g2000cwe.googlegroups.com...
> Sisyphus wrote:
..
..
> > Find the'LIBS' and 'INC' entries in the WriteMakefile() section of said
> > Makefile.PL and change them to something like:
> >
> > 'LIBS' => [join(' ','/home/me/opt/lib',@LIBPATH,@LIBS)],
> > 'INC' => join(' ','/home/me/opt/include',@INC),
> >
> > Then just run 'make clean' and start over again - responding to all
prompts
> > as usual.
>
..
..
>
> ** WARNING: found gd.h header file in /usr/includegd.h, but it is
> expected at /home/me/opt/include/gd.h. This may cause compile errors!
> **
>
>
> ** WARNING: found gd.h header file in /usr/include/gd.h, but it is
> expected at /home/me/opt/include/gd.h. This may cause compile errors!
> **
You're sure that /home/me/opt/include/gd.h exists ? .... it's not (eg)
/home/me/opt/include/gd/gd.h ?
How about:
'LIBS' => [join(' ','-L/home/me/opt/lib',@LIBPATH,@LIBS)],
'INC' => join(' ','-I/home/me/opt/include',@INC),
(Sorry about that ... without the '-L' and '-I' switches those first
elements achieve nothing.)
Turns out that on Win32, all I really need to do is have:
'LIBS' => [join(' ',@LIBPATH,@LIBS)],
'INC' => join(' ',@INC),
And both gd.h and libgd.a are found correctly - so long as I provide the
correct location of libgd.a when prompted by the Makefile.PL. Based on the
reported location of your gd.h and libgd.a, the same should be happening for
you .... don't knowwhy that's not the case. Anyway, try inserting the '-L'
and '-I' (that's uppercase i) and see if that helps. (For me, libgd.a is in
D:/MSYS/local/lib and gd.h is in D:/MSYS/local/include.)
Cheers,
Rob
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 11.11.2006 04:07:29 von jmg3000
Sisyphus wrote:
> wrote in message
> news:1163189085.570476.64880@e3g2000cwe.googlegroups.com...
> > Sisyphus wrote:
> .
> .
> > > Find the'LIBS' and 'INC' entries in the WriteMakefile() section of said
> > > Makefile.PL and change them to something like:
> > >
> > > 'LIBS' => [join(' ','/home/me/opt/lib',@LIBPATH,@LIBS)],
> > > 'INC' => join(' ','/home/me/opt/include',@INC),
> > >
> [snip]
>
> You're sure that /home/me/opt/include/gd.h exists ? .... it's not (eg)
> /home/me/opt/include/gd/gd.h ?
Yup to the former. That header is where it's supposed to be.
> How about:
>
> 'LIBS' => [join(' ','-L/home/me/opt/lib',@LIBPATH,@LIBS)],
> 'INC' => join(' ','-I/home/me/opt/include',@INC),
>
> (Sorry about that ... without the '-L' and '-I' switches those first
> elements achieve nothing.)
Whoops. That slipped by me too. I made the change, but still get the
same results. (Incidentally, I noticed that, in the resulting makefile,
there's some duplication now, with that path getting mentioned in a
number of places twice in a row).
> Turns out that on Win32, all I really need to do is have:
>
> 'LIBS' => [join(' ',@LIBPATH,@LIBS)],
> 'INC' => join(' ',@INC),
Hm.
> And both gd.h and libgd.a are found correctly - so long as I provide the
> correct location of libgd.a when prompted by the Makefile.PL.
Wait. How is it that you're getting prompted somehow for libgd.a? I'd
be happy to statically link to libgd.a, but don't yet know how. How do
I tell GD's Makefile.PL that I'd like to statically link to libgd? That
would actually solve my problem here pretty nicely. When I built libgd,
I got both the .so and the .a in ~/opt/lib.
BTW, currently, when running "perl Makefile.PL LIB=/home/me/perllib",
I'm not getting prompted for anything, since the new libgd I built has
its own gdlib-config in ~/opt/bin which is evidently being used
correctly by GD's Makefile.PL.
Thanks for all the help! :)
---John
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 11.11.2006 06:43:48 von Sisyphus
wrote in message
news:1163214449.062467.90280@h48g2000cwc.googlegroups.com...
..
..
> Wait. How is it that you're getting prompted somehow for libgd.a?
From the Makefile.PL:
my $PREFIX = $lib_gd_path;
if( ! defined($lib_gd_path) )
{
warn "\n";
$PREFIX = prompt('Where is libgd installed?','/usr/lib');
}
But, of course, $lib_gd_path will already have been defined for you by
gdlib-config - which is not being found in my case. I do have gdlib-config,
but my cmd.exe shell wouldn't be able to use it directly - even if it could
find it.
I just keep thinking that there must be some hardcoded 'LIBS' and 'INC'
entry that will do the trick - since that's what gets used to write the
makefile.
> I'd
> be happy to statically link to libgd.a, but don't yet know how. How do
> I tell GD's Makefile.PL that I'd like to statically link to libgd? That
> would actually solve my problem here pretty nicely. When I built libgd,
> I got both the .so and the .a in ~/opt/lib.
I thought that '-lgd' would have the linker link to 'libgd.a' rather than
'libgd.so' - because it would use the first file it finds and it would find
libgd.a before finding libgd.so. (I could be wrong about that, too.)
Is the .a a static library ? ... or is it merely an import library for the
..so ?
In my case, libgd.a *is* a static library - there is *no* shared library.
And I had to therefore take the additional step of altering the 'DEFINES'
entry in the WriteMakefile() section to:
'DEFINES' => $defines . " -DNONDLL"
The same may not apply in non-windows environments. If it *does* apply then
it's unlikely to be '-DNONDLL' - more likely something like '-DNONSO'.
In any case, if the .a is just an import lib for the .so, then you shouldn't
have to worry about any of that.
>
> BTW, currently, when running "perl Makefile.PL LIB=/home/me/perllib",
> I'm not getting prompted for anything, since the new libgd I built has
> its own gdlib-config in ~/opt/bin which is evidently being used
> correctly by GD's Makefile.PL.
>
Yes - and I don't know why is allowing the /usr/include/gd.h to get in the
way. Might pay to run 'gdlib-config --all' and check that it's not throwing
up something you don't want.
> Thanks for all the help! :)
>
Hmmm ... I fear that all I have yet provided is more appropriately
classified as "red herrings" rather than "help" :-)
I've just fired up my linux box. Initially I got warnings, too, about
another gd.h in /usr/include. Renaming it (and gd_io.h) so that they
wouldn't get found fixed that - but didn't make any difference when it came
to building GD. 'make' runs ok, but the perl GD.so cannot be loaded because
of an undefined symbol - different symbol to the one that's tripping you up.
I have only gd-2.0.28, and I'm not confident that's sufficiently recent for
GD-2.35 (despite the claim made by the Makefile.PL).
I don't know why that animated gif symbol is not being resolved for you. If
you don't need animated gif support you could try building GD-2.35 without
it - but that's another kludge you should not have to be bothered with.
Cheers,
Rob
Re: building GD using a locally-installed libgd (old libgd also present on system)
am 12.11.2006 05:00:05 von jmg3000
Sisyphus wrote:
> wrote in message
> [sinp]
>
> I just keep thinking that there must be some hardcoded 'LIBS' and 'INC'
> entry that will do the trick - since that's what gets used to write the
> makefile.
Possibly. Though, I'm now guessing the "right way"(tm) to do it is to
set various variables on the "perl Makefile.PL FOO=bar" command line as
described in the ExtUtils::MakeMaker docs. I've tried various
combinations of those, but have not had any luck. For example, tried:
perl Makefile.PL LIB=/home/me/perllib LINKTYPE=static
INC=/home/me/opt/include LIBS=/home/me/opt/lib/libgd.a
and
perl Makefile.PL LIB=/home/me/perllib LINKTYPE=static
INC=/home/me/opt/include LIBS=/home/me/opt/lib
with no luck.
> > I'd
> > be happy to statically link to libgd.a, but don't yet know how. How do
> > I tell GD's Makefile.PL that I'd like to statically link to libgd? That
> > would actually solve my problem here pretty nicely. When I built libgd,
> > I got both the .so and the .a in ~/opt/lib.
>
> I thought that '-lgd' would have the linker link to 'libgd.a' rather than
> 'libgd.so' - because it would use the first file it finds and it would find
> libgd.a before finding libgd.so. (I could be wrong about that, too.)
I think that '-lgd' tell the link editor to try and link in libgd.so
only.
> Is the .a a static library ? ... or is it merely an import library for the
> .so ?
It's a static lib. I think the term "import library" is a
Windows-specific thing, but I'm not familiar with it. On GNU/Linux, we
have static libs (.a) and shared libs (.so).
> In my case, libgd.a *is* a static library - there is *no* shared library.
> And I had to therefore take the additional step of altering the 'DEFINES'
> entry in the WriteMakefile() section to:
>
> 'DEFINES' => $defines . " -DNONDLL"
>
> The same may not apply in non-windows environments. If it *does* apply then
> it's unlikely to be '-DNONDLL' - more likely something like '-DNONSO'.
Dunno. Though, I still feel like MakeMaker should be smarter than this.
That is, I should be able to simply tell it to please link only to the
static lib for libgd... I'll have to research this a bit more. It's
gotta be a pretty commonly-needed thing...
> [snip]
> > Thanks for all the help! :)
> >
>
> Hmmm ... I fear that all I have yet provided is more appropriately
> classified as "red herrings" rather than "help" :-)
Then thank you for your time. :)
For now, my plan is to dig around and find out how to properly use
MakeMaker so I can tell it to statically link to libgd.
---John