installing GD.pm

[morgon]

Hi,

I have a problem installing GD on debian.

I have installed the libgd-dev package and when I try to build the GD-module I get the following warning:

** WARNING: found gd.h header file in /usr/includegd.h, but it is expe
+cted at /gd.h. This may cause compile errors! **

** WARNING: found gd.h header file in /usr/includegd.h, but it is expe
+cted at /gd.h. This may cause compile errors! **

Regardless of the warnings the compilation completes (a GD.o is created), but then the tests fail:

t/Polyline.t .. Can't locate loadable object for module GD in @INC (@I
+NC contains: /home/mh/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/
+5.18.1/x86_64-linux-thread-multi /home/mh/perl5/perlbrew/perls/perl-5
+.18.1/lib/site_perl/5.18.1 /home/mh/perl5/perlbrew/perls/perl-5.18.1/
+lib/5.18.1/x86_64-linux-thread-multi /home/mh/perl5/perlbrew/perls/pe
+rl-5.18.1/lib/5.18.1 .) at GD/Polyline.pm line 45.

Anyone seen this before?

UPDATE: I have now tried to use the libgd2-xpm packages from stable (I am using debian testing). Using that I do not get any warnings when the Makefile is created and the compilation also succeeds but in the end I get the same error.

[syphilis]

Regardless of the warnings the compilation completes (a GD.o is created)

But it's the GD.so (not GD.o) that's being sought and not located.

t/Polyline.t .. Can't locate loadable object for module GD in @INC (@INC contains: /home/mh/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/5.18.1/x86_64-linux-thread-multi /home/mh/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/5.18.1 /home/mh/perl5/perlbrew/perls/perl-5.18.1/lib/5.18.1/x86_64-linux-thread-multi /home/mh/perl5/perlbrew/perls/perl-5.18.1/lib/5.18.1 .) at GD/Polyline.pm line 45.

At this stage the GD.so will be in a blib folder - but I don't see "blib" mentioned anywhere in the above error message. (For the running of 'make test' it *should* be there.)
After you've run 'make install', the GD.so should have been placed in a position where it *does* get found with the above @INC. This would explain that the module then works fine.

Does the same problem occur when you build other perl extensions ?
It won't be a problem with "pure perl" modules - but for extensions (ie those modules that involve C code that needs to be compiled) this ought to be working properly.
If the problem does not arise with other extensions, then the GD source distro would seem to be the culprit. Otherwise, it's something else ;-)

Cheers,
Rob

[morgon]

Sorry for confusing things, I wanted to refer to GD.so.

Both GD.o and GD.so are created, GD.o in the top level, GD.so in blib/arch/auto/GD. running ldd on GD.so shows no missing libraries.

The output from running "make test" gave me no indication about what was going wrong, so I resorted to run the test-scripts manually - this is how I generated the output I posted.

So far I did not have any problem with the GD.pm that I installed regardless of the failed tests, still I would like to understand what the problem was - I will repeat the excercise on another machine and see what happens there...

[syphilis]

so I resorted to run the test-scripts manually

I'm not entirely sure of the way you did that ... though I feel I ought to be able to deduce it from the output you provided.
Prior to installing the module, you need to run that test script as perl -Mblib t/polyline.t

If that's what you did, then I'm still puzzled as to the absence of blib in @INC - it *should* be there.

Of course, after you've installed the module, you should be able to run that script as simply perl t/polyline.t

(This may well have little or nothing to do with the problem you're trying to solve, but it's at least a bit of a puzzle in itself.)

Cheers,
Rob

[zentara]

** WARNING: found gd.h header file in /usr/includegd.h, but it is expe +cted at /gd.h. This may cause compile errors! **

There is your error, right there. See how it found a file /usr/includegd.h ?? It should read /usr/include/gd.h. Somehow one of the software repository template or make files got screwed up, and lost a /. It happens. I was just watching a youtube video of Linus Torvalds explain why Git is so valuable, because it always returns exactly what was put in.

C libraries need correct header files.

[zentara]

I've built GD from library source many times. Your Debian libgd-dev packages seem to be damaged and one of the install scripts missed a '/' in it's file path. I'm surprised it even ran as it did. It built the library, but without the proper .h header file, the library was useless.

Get the GD source linked to above, build it yourself, it only takes a few minutes. Watch for errors. Install it as root, then reinstall the Perl Gd module.

[morgon]

I don't think the package is damaged (after all I've tried the packages from both stable and testing).

As I need GD.pm only because it is a dependency for some other software and I was not really sure that it would be even needed for my use-case I did a "make install" to see what would happen - and it seems to work. I can run all the demos, no errors.

For whatever reason the problem I have only seems to affect the "make test".

Weird.

[taint]

Greetings, morgon.

"Anyone seen this before?"
Up until recently, I would have said no. But recently (1067745), and another (node ID unknown) only 2 days prior, also was related to the problem you indicate your facing. Given the output you've provided. It appears the I isn't being properly populated in make, or configure. Given that it assumes / for gd.h. I'd also be looking at PERFIX; as in PERFIX= /usr, or /usr/local. While it's easy to say it's the install(er). I wouldn't jump to any conclusions.

I'd need to have it in front of me to properly diagnose it (I'm on *BSD). But if you have the ability. You might try configureconfigure --help, or configureconfigure -h, for any clues it may provide.

--Chris

UPDATE: provided links for Debian's configure
See also: autoconf

[Anonymous Monk]

Why don't you run ldd to diagnose this issue?

Should have saved my ldd links I gave you :)

[Anonymous Monk]

I did run ldd on the generated GD.so (this was the first thing I did in fact).

Everything resolved, no missing libraries.

So what do you mean by "diagnonse further"?