question about installation of GD::Text on cygwin (could be a Makefile q)

U

Upstart

Hi

For background: I am trying to install a few modules with an
environment of Cygwin w/ windows 2000. The module I am stuck on is
GD::Text.

tried this post on the *.modules list with no luck.

Went to cygwin to download latest and greatest code, and they seem to
package freetype and the GD library now. So I downloaded them and
installed, then was able to successfully build GD.pm.

Now I downloaded GD::Text 0.86. I do a 'perl Makefile.PL' and it won't
drop/create a Makefile. I downloaded 0.85 and got the same results:

$ perl Makefile.PL
Checking if your kit is complete...
Looks good

$


that's it... no Makefile. no error messages. I am building other
modules (Like GD) and this step builds a Makefile with those modules.

How would I trouble shoot this? I guess it would have to do with the
ExtUtils::MakeMaker module.... but I don't know how to troubleshoot
this kind of fundamental problem.

JIM
 
R

Randy Kobes

Upstart said:
Hi

For background: I am trying to install a few modules with an
environment of Cygwin w/ windows 2000. The module I am stuck on is
GD::Text.

tried this post on the *.modules list with no luck.

Went to cygwin to download latest and greatest code, and they seem to
package freetype and the GD library now. So I downloaded them and
installed, then was able to successfully build GD.pm.

Now I downloaded GD::Text 0.86. I do a 'perl Makefile.PL' and it won't
drop/create a Makefile. I downloaded 0.85 and got the same results:

$ perl Makefile.PL
Checking if your kit is complete...
Looks good

$

that's it... no Makefile. no error messages. I am building other
modules (Like GD) and this step builds a Makefile with those modules.

How would I trouble shoot this? I guess it would have to do with the
ExtUtils::MakeMaker module.... but I don't know how to troubleshoot
this kind of fundamental problem.

If you comment out all the stuff at the beginning of Makefile.PL
involving eval{}, and just leave the WriteMakefile() call in, is a
Makefile produced?

best regards,
randy kobes
 
M

Martien Verbruggen

Hi

For background: I am trying to install a few modules with an
environment of Cygwin w/ windows 2000. The module I am stuck on is
GD::Text.
$ perl Makefile.PL
Checking if your kit is complete...
Looks good

$


that's it... no Makefile. no error messages. I am building other
modules (Like GD) and this step builds a Makefile with those modules.

Hmmm.. That's odd. I've never had a report about this before.

Would it be possible for you to comment out bits and pieces from the
makefile.PL file to see whether there is something that causes this,
and if so what it is?
How would I trouble shoot this? I guess it would have to do with the
ExtUtils::MakeMaker module.... but I don't know how to troubleshoot
this kind of fundamental problem.

Try commenting out everything but the call to WriteMakefile(). Then
uncomment the MY::postamble, then MY::libscan, then one by one the two
tests (eval followed by if) at the top. None of it should break the
writing of a Makefile, but at least we'll know what does it. Maybe a
few well-placed debugging statements in the breaking bits could
pinpoint it a bit more.

I don't really see anything in the code that could cause this sort of
breakage though....

Martien
 
U

Upstart

Randy Kobes said:
If you comment out all the stuff at the beginning of Makefile.PL
involving eval{}, and just leave the WriteMakefile() call in, is a
Makefile produced?

Ok... started hacking at this...

Try commenting out everything but the call to WriteMakefile(). Then
uncomment the MY::postamble, then MY::libscan, then one by one the two
tests (eval followed by if) at the top. None of it should break the
writing of a Makefile, but at least we'll know what does it. Maybe a
few well-placed debugging statements in the breaking bits could
pinpoint it a bit more.

I don't really see anything in the code that could cause this sort of
breakage though....

Couple of things as a result of this direction (thanks to both guys
for direction):

- I have isolated the code snippet(s) that cause the problem. The hash
value for PREREQ_PM and the "TTF eval" (see diff below).
- There is no MY::libscan in the Makefile.PL, only postamble.
- If I add a "use GD;" line at the top of the page, the silent failure
to create a Makefile is exhibited again. I did this to see if my GD
was broken. I am running GD 2.11.
- I have confirmed that my GD implementation works by creating a
simple black jpeg
- removing these sections allowed me to create the Makefile. I could
send if anyone is interested. I don't know if this is valid yet. I
will run tomorrow.

Here is the diff:

$ diff Makefile.PL Makefile.f
5c5
<
---
17,32d16
< eval
< {
< local $SIG{'__WARN__'};
< require GD;
< require File::Spec;
< require Cwd;
<
< GD::Image->can('stringTTF')
< or die "One";
< GD::Image->stringTTF(0, 'foo', 10, 0, 0, 0, 'foo');
< $@ =~ /TrueType font support/i
< and die "Two";
< my $test_font = File::Spec->catfile(Cwd::cwd(),
"Dustismo_Sans.ttf");
< GD::Image->stringTTF(0, $test_font, 10, 0, 0, 0, 'foo')
< or die "Three: $@";
< };
55,56c39
< 'VERSION_FROM' => 'Text.pm',
'VERSION_FROM' => 'Text.pm',

and here is the GD snippet I used to make sure I could create an image
file from GD.

#!/usr/bin/perl
#
use GD;

$image = new GD::Image(50,50) or die "Couldn't Create Image";

open OUTFILE, ">output.gif";
binmode OUTFILE;
print OUTFILE $image->jpeg;
close OUTFILE;
 
M

Martien Verbruggen

[snip]
If you comment out all the stuff at the beginning of Makefile.PL
involving eval{}, and just leave the WriteMakefile() call in, is a
Makefile produced?

Ok... started hacking at this...

Try commenting out everything but the call to WriteMakefile(). Then
uncomment the MY::postamble, then MY::libscan, then one by one the two
tests (eval followed by if) at the top. None of it should break the
writing of a Makefile, but at least we'll know what does it. Maybe a
few well-placed debugging statements in the breaking bits could
pinpoint it a bit more.

I don't really see anything in the code that could cause this sort of
breakage though....

Couple of things as a result of this direction (thanks to both guys
for direction):

- I have isolated the code snippet(s) that cause the problem. The hash
value for PREREQ_PM and the "TTF eval" (see diff below).

The PREREQ_PM line broke the creation of a Makefile? Without messages?
- There is no MY::libscan in the Makefile.PL, only postamble.

You're right. I was looking at my working copy, not realising that I
had changed Makefile.PL after 0.86.
- If I add a "use GD;" line at the top of the page, the silent failure
to create a Makefile is exhibited again. I did this to see if my GD
was broken. I am running GD 2.11.

That is odd. very odd. I don't see how the inclusion of GD would
conflict with MakeMaker.

Just for the heck of it, could you do something like:

$ cd /tmp
$ h2xs -ACXn Foo
Writing Foo/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/test.pl
Writing Foo/MANIFEST
$ cd Foo
[edit Makefile.PL and put "use GD;" near the top]
$ perl Makefile.PL

If that breaks, then the problem is somewhere in the interaction
between GD and MakeMaker, and that's probably worth a bug report to
either P5P of Lincoln Stein.

If that doesn't break, please continue...
- I have confirmed that my GD implementation works by creating a
simple black jpeg
- removing these sections allowed me to create the Makefile. I could
send if anyone is interested. I don't know if this is valid yet. I
will run tomorrow.

Here is the diff:

$ diff Makefile.PL Makefile.f
5c5
<
---
17,32d16
< eval
< {
< local $SIG{'__WARN__'};
< require GD;
< require File::Spec;
< require Cwd;
<
< GD::Image->can('stringTTF')
< or die "One";
< GD::Image->stringTTF(0, 'foo', 10, 0, 0, 0, 'foo');
< $@ =~ /TrueType font support/i
< and die "Two";
< my $test_font = File::Spec->catfile(Cwd::cwd(),
"Dustismo_Sans.ttf");
< GD::Image->stringTTF(0, $test_font, 10, 0, 0, 0, 'foo')
< or die "Three: $@";
< };

And I do need to test for this. I got too many reports about tests
failing, only to have to talk the person reporting it through
correctly installing GD. This test is there to prevent those GD
installations where libgd is compiled differently from GD to cause my
mailbox to be filled.

What I'd like to know is why this piece of code causes Makefile.PL
_not_ to write out a Makefile. It's all neatly wrapped in an eval.
I'd expect the test to either fail, or not. In either case, nothing in
here should influence anything outside of the code block and the
following if block.

I don't think I will remove the test from the distribution. I'm
willing to fix whatever is breaking here, even though I don't believe
anything should be breaking.

I don't have your platform, so I can't even begin to try to reproduce
this. Could you give me some more information about your platform?
Versions of cygwin, perl, ExtUtils::MakeMaker, GD, Cwd, File::Spec,
etc? I know I'm asking a bit here, but the alternative is that I have
to write it up as a "broken installation" and ignore the problem. I'd
rather try to find out what exactly the problem is.

Just a weird hunch: If you change the "require Cwd;" to "use Cwd;",
does that change anything? It shouldn't, but you never know... And
File::Spec? Both modules are used internally in the MakeMaker stuff,
maybe the missing import is confusing things, even though I believe it
shouldn't.

The remark about "use GD;" earlier indicates that the "require GD;"
breaks things. However, that is just too weird.
55,56c39
< 'VERSION_FROM' => 'Text.pm',
< 'PREREQ_PM' => { 'GD' => 1 },

Hmmm.. I'd like to leave this in. Maybe I'll just set it to 0. Could
you try that instead? GD::Text has a prerequisite that some version of
GD is installed, so I'd like the Makefile.PL to express that.


Martien
 
U

Upstart

For background: I am trying to install a few modules with an
environment of Cygwin w/ windows 2000. The module I am stuck on is
GD::Text.
[snip]
that's it... no Makefile. no error messages. I am building other
modules (Like GD) and this step builds a Makefile with those modules.

That is odd. very odd. I don't see how the inclusion of GD would
conflict with MakeMaker.

Just for the heck of it, could you do something like:

[snip]

I will try this and post results...
And I do need to test for this. I got too many reports about tests
failing, only to have to talk the person reporting it through
correctly installing GD. This test is there to prevent those GD
installations where libgd is compiled differently from GD to cause my
mailbox to be filled.

What I did do is a print "$@\n"; after each test in the eval block doing
expression testing against $@ to see what is in that variable and I get:

$ perl Makefile.PL
Could not find/open font
Could not find/open font

So something is up with the die statement and the fact that it could not
find the test font in its' own directory! Also, could not find/open font
is not causing it to die... also "One" says 'or die' and "Two" says 'and
die'.

I don't have your platform, so I can't even begin to try to reproduce
this. Could you give me some more information about your platform?
Versions of cygwin, perl, ExtUtils::MakeMaker, GD, Cwd, File::Spec,
etc?

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3
Cygwin DLL version info:DLL version: 1.5.5
perl 5.8.2-1

$ perl -v

This is perl, v5.8.2 built for cygwin-thread-multi-64int

gd 2.0.15-1
libfreetype2-devel 2.1.5-1
libfreetype26 2.1.5-1
libgd-devel 2.0.15-1
libgd2 2.0.15-1
libgdbm 1.8.0-5
libjpeg62 6b-11
libjpeg6b 6b-8

/usr/lib/perl5 $ find . -name GD.pm -print
../site_perl/5.8.0/cygwin-multi-64int/GD.pm
../site_perl/5.8.2/cygwin-thread-multi-64int/GD.pm

version 2.11

$ find . -name MakeMaker.pm -print
../5.8.2/ExtUtils/MakeMaker.pm

version 6.17

$ find . -name Cwd.pm -print
../5.8.2/cygwin-thread-multi-64int/Cwd.pm
version 2.08

$ find . -name Spec.pm -print
../5.8.2/File/Spec.pm

version 0.86

Is the two versions of GD.pm causing the hiccup? Or should perl just
figure it out based on which perl is in the shebang/path?
Just a weird hunch: If you change the "require Cwd;" to "use Cwd;",
does that change anything? It shouldn't, but you never know... And
File::Spec? Both modules are used internally in the MakeMaker stuff,
maybe the missing import is confusing things, even though I believe it
shouldn't.

ok so the eval block has:

eval
{
local $SIG{'__WARN__'};
require GD;
use File::Spec;
use Cwd;
.....

With/without 'PREREQ_PM' => { 'GD' => 1 },

and got the same results. Also set the anonymous hash to 0.
Hmmm.. I'd like to leave this in. Maybe I'll just set it to 0. Could
you try that instead? GD::Text has a prerequisite that some version of
GD is installed, so I'd like the Makefile.PL to express that.

I set it to 0 and got the same results... even with the eval block
removed.

JIM
 
B

Ben Morrow

/usr/lib/perl5 $ find . -name GD.pm -print
./site_perl/5.8.0/cygwin-multi-64int/GD.pm
./site_perl/5.8.2/cygwin-thread-multi-64int/GD.pm
Is the two versions of GD.pm causing the hiccup? Or should perl just
figure it out based on which perl is in the shebang/path?

Aha! I think this may be your problem. Try the following:

perl -le'print for @INC'

and then try adding

$\ = "\n";
print for @INC;

to the top of Makefile.PL, *before* it makes any attempt to load
GD.pm. If either of those lists have the 5.8.0 dir before the 5.8.2
dir, that is your problem: extensions built against a perl without
threading are binary-incompatible with perls with.

If you don't have 5.8.0 installed any more you can just remove that
GD.pm, or indeed the whole 5.8.0/cygwin-multi-64int
directory. Otherwise you need to fix whatever it is is getting your
@INC in the wrong order: 5.8.2 dirs should be tried before 5.8.0
dirs.

Ben
 
U

Upstart

Aha! I think this may be your problem. Try the following:

perl -le'print for @INC'

and then try adding

$\ = "\n";
print for @INC;

to the top of Makefile.PL, *before* it makes any attempt to load
GD.pm. If either of those lists have the 5.8.0 dir before the 5.8.2
dir, that is your problem: extensions built against a perl without
threading are binary-incompatible with perls with.

This seems to be doing the right thing. Here is output:

$ perl Makefile.jim
/home/jhall/lib/perl5
/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int
/usr/lib/perl5/5.8.2
/usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl
..
Could not find/open font

Could not find/open font

Checking if your kit is complete...

Looks good

I then actually removed the all the 5.8.0 stuff just to be sure and
got the same results.... thanks for the help though!

JIM
 
U

Upstart

Martien Verbruggen said:
Just for the heck of it, could you do something like:

$ cd /tmp
$ h2xs -ACXn Foo
Writing Foo/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/test.pl
Writing Foo/MANIFEST
$ cd Foo
[edit Makefile.PL and put "use GD;" near the top]
$ perl Makefile.PL

This breaks!

$ h2xs -ACXn Foo
Defaulting to backwards compatibility with perl 5.8.2
If you intend this module to be compatible with earlier perl versions,
please
specify a minimum perl version with the -b option.

Writing Foo/lib/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/t/Foo.t
Writing Foo/MANIFEST

$ cat Makefile.PL
use 5.008002;
use ExtUtils::MakeMaker;
use GD; # jim add
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
NAME => 'Foo',
VERSION_FROM => 'lib/Foo.pm', # finds $VERSION
PREREQ_PM => {}, # e.g., Module::Name => 1.1
($] >= 5.005 ? ## Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'lib/Foo.pm', # retrieve abstract from module
AUTHOR => 'Foo <[email protected]>') : ()),
);

$ perl Makefile.PL
Checking if your kit is complete...
Looks good

$

Silent failure to create a Makefile.
If that breaks, then the problem is somewhere in the interaction
between GD and MakeMaker, and that's probably worth a bug report to
either P5P of Lincoln Stein.

What would be the most effective way to proceed? It is a bummer the
way this thing is not throwing some kind of error message. Is there a
debug switch somewhere?

Is there anybody out there who has my combination of a platform (win
2000, perl 5.8.2, cygwin) that has got this to work recently?

JIM
 
M

Martien Verbruggen

Martien Verbruggen said:
Just for the heck of it, could you do something like:

$ cd /tmp
$ h2xs -ACXn Foo
Writing Foo/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/test.pl
Writing Foo/MANIFEST
$ cd Foo
[edit Makefile.PL and put "use GD;" near the top]
$ perl Makefile.PL

This breaks!

$ h2xs -ACXn Foo [snip]
$ cat Makefile.PL
use 5.008002;
use ExtUtils::MakeMaker;
use GD; # jim add
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
NAME => 'Foo',
VERSION_FROM => 'lib/Foo.pm', # finds $VERSION
PREREQ_PM => {}, # e.g., Module::Name => 1.1
($] >= 5.005 ? ## Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'lib/Foo.pm', # retrieve abstract from module
AUTHOR => 'Foo <[email protected]>') : ()),
);

$ perl Makefile.PL
Checking if your kit is complete...
Looks good

Hmmm. Looks like there's something that's odd with the way GD works in
this environment.
$

Silent failure to create a Makefile.


What would be the most effective way to proceed? It is a bummer the
way this thing is not throwing some kind of error message. Is there a
debug switch somewhere?

I'll have a look to see whether I can reproduce it in my environment.
I haven't actually got 5.8.2 installed yet, but I should. If the same
happens here (non-cygwin) I'll submit a bug report. If not, I'll get
back here, and someone with cygwin shuld probably try to figure ut
what the story is.
Is there anybody out there who has my combination of a platform (win
2000, perl 5.8.2, cygwin) that has got this to work recently?

Martien
 
M

Martien Verbruggen

Martien Verbruggen said:
Just for the heck of it, could you do something like:

$ cd /tmp
$ h2xs -ACXn Foo
Writing Foo/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/test.pl
Writing Foo/MANIFEST
$ cd Foo
[edit Makefile.PL and put "use GD;" near the top]
$ perl Makefile.PL

This breaks!

$ h2xs -ACXn Foo
[snip]

I just created a fresh installation of Perl 5,8.2 on my platform:

$ /opt/perl-5.8.2/bin/perl -v

This is perl, v5.8.2 built for i686-linux
[snip]

and installed GD in there, linked against libgd 2.0.15

$ /opt/perl-5.8.2/bin/perl -MGD -le 'print $GD::VERSION'
2.11

$ ldd /opt/perl-5.8.2/lib/site_perl/5.8.2/i686-linux/auto/GD/GD.so
libgd.so.2 => /opt/gd-2.0.15/lib/libgd.so.2 (0x40014000)
[snip]

That GD is linked against libfreetype 2.1.3.

The MakeMaker is the standard 6.17 version that comes with 5.8.2.

$ /opt/perl-5.8.2/bin/h2xs -ACXn Foo
Defaulting to backwards compatibility with perl 5.8.2
If you intend this module to be compatible with earlier perl versions,
please
specify a minimum perl version with the -b option.

Writing Foo/lib/Foo.pm
Writing Foo/Makefile.PL
Writing Foo/README
Writing Foo/t/Foo.t
Writing Foo/MANIFEST
$ cd Foo
$ vi Makefile.PL
$ /opt/perl-5.8.2/bin/perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Foo

So that works fine.

And in my current checkout of the GD::Text modules:

$ cd ~/src/GDTextUtils
$ make distclean
[snip]
$ /opt/perl-5.8.2/bin/perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for GD::Text
$ make test
cp Text.pm blib/lib/GD/Text.pm
cp Text/Wrap.pm blib/lib/GD/Text/Wrap.pm
cp Text/Align.pm blib/lib/GD/Text/Align.pm
PERL_DL_NONLAZY=1 /opt/perl-5.8.2/bin/perl "-MExtUtils::Command::MM"
"-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/align....ok
5/21 skipped: Some TTF tests disabled: Freetype inconsistent
t/text.....ok
2/20 skipped: Some TTF tests disabled: Freetype inconsistent
t/wrap.....ok
2/14 skipped: Some TTF tests disabled: Freetype inconsistent
All tests successful, 9 subtests skipped.
Files=3, Tests=55, 1 wallclock secs ( 0.59 cusr + 0.09 csys = 0.68 CPU)


Which is also all as expected.


So, my conclusion would be that the problem is not related to Perl, GD,
libgd or freetype, and their interaction.

I believe it is either something that is broken in the cygwin
installation in general (unlikely), or in your installation
specifically.


If someone else could run the above tests on Cygwin as well, that might
shed some light on things, or maybe you could try getting a clean
installation of cygwin to try things on?
I'll have a look to see whether I can reproduce it in my environment.
I haven't actually got 5.8.2 installed yet, but I should. If the same
happens here (non-cygwin) I'll submit a bug report. If not, I'll get
back here, and someone with cygwin shuld probably try to figure ut
what the story is.

At the moment, I can't see that either GD or Perl are to blame, so
neither of the above should get a bug report. It could still be a Cygwin
problem, but it's looking more and more like it might be something local
in your installation.

That would be a good way to find out whether it's a more general Cygwin
issue, or something local to your machine.

Anyway, I can't help any further, I think, since I tend to not use
Windows platforms unless I have to. I don't have one easily available to
me on which I can quickly cobble together a fresh environment.

Martien
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top