Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling


by morgon (Curate)
on Dec 23, 2013 at 10:56 UTC ( #1068171=perlquestion: print w/replies, xml ) Need Help??
morgon has asked for the wisdom of the Perl Monks concerning the following question:


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

Replies are listed 'Best First'.
Re: installing
by syphilis (Chancellor) on Dec 23, 2013 at 22:07 UTC
    Regardless of the warnings the compilation completes (a GD.o is created)

    But it's the (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/ line 45.

    At this stage the 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 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 ;-)

      Sorry for confusing things, I wanted to refer to

      Both GD.o and are created, GD.o in the top level, in blib/arch/auto/GD. running ldd on 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 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...

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

Re: installing
by zentara (Archbishop) on Dec 23, 2013 at 14:36 UTC
    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.

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
      I don't think the package is damaged (after all I've tried the packages from both stable and testing).

      As I need 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".


Re: installing
by zentara (Archbishop) on Dec 24, 2013 at 15:53 UTC
    ** 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.

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Re: installing
by taint (Chaplain) on Dec 23, 2013 at 14:59 UTC
    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.


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

    λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Re: installing (ldd)
by Anonymous Monk on Dec 24, 2013 at 04:12 UTC

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

    Should have saved my ldd links I gave you :)

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

      Everything resolved, no missing libraries.

      So what do you mean by "diagnonse further"?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1068171]
Approved by hdb
[Corion]: Meh. I get the feeling I should post a call-to-action for people to test their modules with the upcoming 5.26 (or 5.25.latest), as it seems that the smoke testers don't really weed out modules that fail without . in @INC
[Corion]: But without instructions on how to easily test things yourself, I don't think such a call to arms is helpful
[Corion]: (this post on / p5p makes it seem to me that smoke testers seem to have a blind spot there)
[Corion]: Hmmm. Maybe setting $ENV{PERL5LIB}=" some path without dot"; perl Makefile.PL; make test already is enough to locally test your module...
[Corion]: Meh, no, will need a BEGIN hook...
[Corion]: ... and PERL5OPT does not like -e in it :-(

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2017-03-27 08:04 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (317 votes). Check out past polls.