You are here: Foswiki>Tasks Web>Item9630 (20 Sep 2010, MichaelDaum)Edit Attach

Item9630: Configure lures people into installing Unicode::MapUTF8 though it is for Perl 5.6 only. This makes configure fail

Priority: Normal
Current State: Closed
Released In: 1.0.10
Target Release: patch
Applies To: Engine
Reported By: IngoKappler
Waiting For:
Last Change By: MichaelDaum

installing the perl module Unicode::MapUTF8 causes the configure page to not load properly anymore (incomplete). It gets stalled after displaying Environment variables (read only), so section CGI setup (read only) and anything else afterwards isn't shown:

Configure stops loading after Environment variables.png
Configure stops loading

It only happens after actually installing Unicode::MapUTF8 and seems not related to the other modules Unicode::MapUTF8 depends on. During debugging I removed them all and installed all other modules (Unicode::String, Unicode::Map, Unicode::Map8) step by step reloading the configure page after each installation. This worked until Unicode::MapUTF8 is being installed. I am mentioning it because I found 2 different points where I can remove a .pm file and the configure page will reload. The 2 files are:

  1. /home/foswiki/perl5/lib/perl5/Unicode/
  2. /home/foswiki/perl5/lib/perl5/i386-linux-thread-multi/Unicode/

It seems to me that is causing the trouble although will also solve the issue if removed but only in case already exists.

Originally I had trouble to get the @INC path being set to /home/foswiki/perl5/lib/perl5/i386-linux-thread-multi and it was because including all modules it depends on were already installed, so it was always ending up with the broken configure page. At this point I assumed some CPAN related installation issue of my local archive and asked the root admins of this CentOS system to install perl-Unicode-MapUTF8-1.09-0.2 system wide with dependencies resolved to also install:

  1. perl-Jcode-2.05-1
  2. perl-Unicode-Map-0.112-1
  3. perl-Unicode-Map8-0.12-0.2
  4. perl-Unicode-String-2.09-1.2

And the issue re-appeared! So we removed all the system wide packages again since it just reproduces what I also get when using the local CPAN modules.

I tried to see something in the log files when loading configure while broken but nothing shows up (not in Foswiki logs nor in Apache).

  • Is there anything that could be done to make the configure page properly displaying, or is this a bug in Unicode::MapUTF8?
  • Is it reproducible on other system not being CentOS?

-- IngoKappler - 06 Sep 2010

I just found a difference comparing the new CentOS installation with my older test system on Debian where this issue is not present although Unicode::MapUTF8 is available:

  1. It uses on Debian perl, v5.10.0 built for i486-linux-gnu-thread-multi
  2. It uses on CentOS perl, v5.8.8 built for i386-linux-thread-multi

-- IngoKappler - 06 Sep 2010

Ingo, so you're saying that your 'older debian' system uses a more recent Perl, where as your 'newer Centos' uses perl 5.8.8?

If we can narrow it down to it being a 5.8.8 issue, then it will be a little easier to resolve :/

Also, is it possible that someone that can reproduce it on 1.0.9 try trunk to make sure its not an issue there too?

-- SvenDowideit - 07 Sep 2010

I was unable to recreate this on gentoo - running perl 5.10.1.

-- GeorgeClark - 07 Sep 2010

Hi, thanks for the responses. Yes, the CentOS version is:
$ cat /etc/*release*
Enterprise Linux Enterprise Linux Server release 5.4 (Carthage)
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
By now there is a CentOS 5.5 avaiable but it doesn't seem to include newer perl packages.

I just got an additional perl-5.10.1 installed from the admins but now have to figure out how to combine it with my local perl repository while at the same time keeping the default 5.8.8 away. Well, I am going to give App::perlbrew a try (Using CPAN with a non-root account) which sounds to give me all the flexibility I need here.

-- IngoKappler - 07 Sep 2010

Unicode::MapUTF8 is a library that you install if you have Perl 5.6.

For Perl 5.8 and later the UTF8 support is part of Perl and it is directly damaging to install this library

Why did you install it? Do we have some bogus installation script that installs it or do we have unclear documentation?

This is a in my view not an urgent bug and maybe not even a bug at all. I will however see if our installation guides are precise enough.

-- KennethLavrsen - 07 Sep 2010

It is configure that lures people to install this out of date CPAN lib. I have change the docu in DEPENDENCIES so you clearly is warned against installing this on anything else than Perl 5.6. And I am not even sure we fully support 5.6 anymore.

-- KennethLavrsen - 07 Sep 2010

Hi Kenneth,

ok, maybe it is not required anymore from a sole configure perspective but according to LdapContrib it is required there. The true reason I started to fight with it is LdapContrib not just configure.

Ah, if you say newer perl versions ship with UTF8 support then our documentation wouldn't be sufficiently precise. Also it would be good to know what then is used instead of Unicode:MapUTF8, so one is able to verify everything is in place.

-- IngoKappler - 08 Sep 2010

Well, I now also read this on this part on the module description:

This module is intended to provide good Unicode support to versions of Perl prior to 5.8. If you are using Perl 5.8.0 or later, you probably want to be using the Encode module instead. This module does work with Perl 5.8, but Encode is the preferred method in that environment.

-- IngoKappler - 08 Sep 2010

UTF8 will be reworked in next LdapContrib so that it only uses this fallback library for older perls. Refiling as Item9721.

-- MichaelDaum - 20 Sep 2010

ItemTemplate edit

Summary Configure lures people into installing Unicode::MapUTF8 though it is for Perl 5.6 only. This makes configure fail
ReportedBy IngoKappler
Codebase 1.0.9, trunk
SVN Range
AppliesTo Engine
Priority Normal
CurrentState Closed
Checkins distro:29e0943eac50 distro:6618ad8f5171 distro:0d25585dcf85
TargetRelease patch
ReleasedIn 1.0.10
Topic revision: r14 - 20 Sep 2010, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy