This one-liner will give you contents of @INC:

 perl -le 'print $_ for @INC'
[download]

But usually that error message includes the paths in @INC. And usually, the install process uses that information to put stuff in the right place. Is there any chance you had more than on version of perl floating around?

Are you sure your install worked?

I'm running perl on rh9 with Tk, no problem. I do recall that I had to muck with something to make the install work though, if you search for perl, Tk and utf8 or utf-8, I think tyou'll find it.

Update: I found references to this by googling about: for

perl tk "red hat 9" LANG
[download]

This is due to the screwed up string handling of Perl in unicode. You can
disable unicode by setting

export LANG="en_US"

first (just type this command before doing perl Makefile.PL )

On my system, it appears that I have unset LANG - I may have actually tracked down where it was being set, I don't remember anymore.

All code given here is UNTESTED unless otherwise stated.

You don't have to set LANG anymore if you're going to use Perl 5.8.1. From Perl 5.8.1's perldelta:

UTF-8 no longer default under UTF-8 locales

In Perl 5.8.0 many Unicode features were introduced. One of them was found to be of more nuisance than benefit: the automagic (and silent) "UTF-8-ification" of filehandles, including the standard filehandles, if the user's locale settings indicated use of UTF-8.

For example, if you had C<en_US.UTF-8> as your locale, your STDIN and STDOUT were automatically "UTF-8", in other words an implicit binmode(..., ":utf8") was made. This meant that trying to print, say, chr(0xff), ended up printing the bytes 0xc3 0xbf. Hardly what you had in mind unless you were aware of this feature of Perl 5.8.0. The problem is that the vast majority of people weren't: for example in RedHat releases 8 and 9 the B<default> locale setting is UTF-8, so all RedHat users got UTF-8 filehandles, whether they wanted it or not. The pain was intensified by the Unicode implementation of Perl 5.8.0 (still) having nasty bugs, especially related to the use of s/// and tr///. (Bugs that have been fixed in 5.8.1)

Therefore a decision was made to backtrack the feature and change it from implicit silent default to explicit conscious option. The new Perl command line option C<-C> and its counterpart environment variable PERL_UNICODE can now be used to control how Perl and Unicode interact at interfaces like I/O and for example the command line arguments. See L<perlrun> for more information.

Liz

Thank you Bob !

As expected Tk is not included in the @INC.


perl -le 'print $_ for @INC'
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
[download]


And in this case I have a situation. I need Unicode enabled because I am coding some pages in Vietnamese.

In my own searches I found a few people with the same issue in adding Tk. And I was hoping for a surgical way to add the Tk directory to the search path, but if Unicode is the issue ... then that is a whole new problem.

You wouldn't typically see the module in the contents of @INC. @INC lists directories where the search for modules start.

I don;t know whether utf-8 has to be turned off all the time or only during the build process - I think the latter, but judging from Liz's post below, you are better of just going for perl 5.8.1.

--Bob Niederman, http://bob-n.com

All code given here is UNTESTED unless otherwise stated.

Wow,

Thanks for all the help everyone.

And I installed what I thought was an RH9 compatible rpm ... PerlTk-8.11-1.i386.rpm.

If I should burn this down, & start over with known good downloads, can you direct me to the right links eg. the Perl 8.5.1 mentioned previously ... just so I am on the same page with everyone else.

Thanks Again Monks