[Bug 166478] glibc or perl incorrect locale LC_CTYPE data
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: glibc or perl incorrect locale LC_CTYPE data
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166478
jvdias(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution| |NOTABUG
------- Additional Comments From jvdias(a)redhat.com 2005-11-02 11:45 EST -------
Sorry I submitted my previous comment before finishing it -
then my machine rebooted (that's another story).
As I was saying in Comment #2 :
This version of your program shows the issue:
---
#!/usr/bin/perl -w -C
use strict;
use utf8;
use locale;
use Encode qw(decode);
my $str = decode('utf-8', "\xc3\x81\xc4\x8c");
# U+00C1 "A with acute", U+010C "C with caron" (encoded in UTF-8)
print 'Is UTF-8:',utf8::is_utf8($str),
' is word:', $str =~ /^\w+$/,
' is UTF-8 word: ', $str =~ /^\p{IsWord}+$/,
' str:',$str, "\n";
---
With the "en_US.UTF-8" locale in effect ( the default on Red Hat systems )
this prints:
$ ./test.pl
Is UTF-8:1 is word: is posix word: 1 is UTF-8 word: 1 str:ÁČ
The point is that \p{IsWord} or [[:word:]] matches UTF-8 word characters,
while \w / \W do not.
As the perlre man-page states:
"
The following equivalences to Unicode \p{} constructs and equivalent
backslash character classes (if available), will hold:
[:...:] \p{...} backslash
...
word IsWord
...
"
ie. the [:word:] / \p{IsWord} classes are NOT equivalent to \w .
As I said, I don't particularly agree with the way the upstream perl
developers have done this, but this is intended behaviour.
RE: your comment #3:
> Your statement that "\w matches any ASCII word char" is not true.
> See perlre(1):
> [...] If "use locale" is in effect, the list of alphabetic characters
> generated by "\w" is taken from the current locale.
Yes, that's alphabetic characters, not unicode sequences.
To match unicode sequences in the word class, you must use \p{IsWord} or
[:word:] .
> So the question is why Perl (or libc) in FreeBSD does consider U+00C1 to be a
> character under the UTF-8 locale, while the same perl with glibc on Linux
> doesn't.
Possibly because the default locale for Red Hat systems is UTF-8 enabled ?
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 5 months
[Bug 166478] glibc or perl incorrect locale LC_CTYPE data
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: glibc or perl incorrect locale LC_CTYPE data
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166478
------- Additional Comments From kas(a)informatics.muni.cz 2005-11-02 05:30 EST -------
Well, then tell me why the same Perl works on FreeBSD. Is it that Linux UTF-8
locales does not consider U+00C1 to be a character, while U+10C is a character?
Your statement that "\w matches any ASCII word char" is not true. See perlre(1):
[...] If "use locale" is in effect, the list of alpha-
betic characters generated by "\w" is taken from the current locale.
See perllocale. [...]
So the question is why Perl (or libc) in FreeBSD does consider U+00C1 to be a
character under the UTF-8 locale, while the same perl with glibc on Linux doesn't.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 5 months
[Bug 166478] glibc or perl incorrect locale LC_CTYPE data
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: glibc or perl incorrect locale LC_CTYPE data
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166478
------- Additional Comments From jvdias(a)redhat.com 2005-11-01 20:29 EST -------
One has to carefully analyse the perl man-pages to find out what is going on here.
I don't particularly agree with the way the upstream perl maintainers have done
this, but this is not a bug - it is the way perl is meant to behave.
The point is that /\w/ matches any ASCII word char, and /\W/ matches any ASCII
non-word char.
To match a UTF-8 word character, you have to use \p{IsWord} .
The \w wildcard is a synonym for the POSIX character class [:word:].
So this version of your program :
---
#!/usr/bin/perl -w -C
use strict;
use utf8;
use locale;
use Encode qw(decode);
my $str = decode('utf-8', "\xc3\x81\xc4\x8c");
# U+00C1 "A with acute", U+010C "C with caron" (encoded in UTF-8)
print 'Is UTF-8:',utf8::is_utf8($str),
' is word:', $str =~ /^\w+$/,'
is UTF-8 word:',
$str =~ /^\p{IsWord}+$/, ' str:',$str, "\n";
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 5 months
[Bug 168373] New: perl is compiled without 64bit int on i386
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168373
Summary: perl is compiled without 64bit int on i386
Product: Fedora Core
Version: devel
Platform: i386
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: normal
Component: perl
AssignedTo: wtogami(a)redhat.com
ReportedBy: redhat(a)olen.net
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
perl is compiled without 64bit int on i386
Version-Release number of selected component (if applicable):
perl-5.8.7-0.3.fc5
How reproducible:
Always
Steps to Reproduce:
1. Install perl
2. perl -e 'printf ("%x", 99999999999999)'
Actual results:
ffffffff
Expected results:
5af3107a3fff
Additional info:
>From the INSTALL manual:
"The use64bitint option does only as much as is required to get 64-bit integers
into Perl (this may mean, for example, using "long longs") while your memory may
still be limited to 2 gigabytes (because your pointers could still be 32-bit).
Note that the name 64bitint does not imply that your C compiler will be using
64-bit ints (it might, but it doesn't have to). The use64bitint simply means
that you will be able to have 64 bit-wide scalar values."
http://search.cpan.org/~nwclark/perl-5.8.6/INSTALL#Run_Configure
At least I need 64bit ints for some internal applications that needs to run on
both x86_64 and i386.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 5 months
[PATCH] h2ph inc_dirs() fails to prepend gcc include search path, resulting in missing C standard headers on Linux
by Jason Vas Dias
To: perlbug(a)perl.org
Subject: h2ph inc_dirs fails to prepend gcc include search path, resulting in missing C standard headers on Linux
Reply-To: jvdias(a)redhat.com
Message-Id: <5.8.7_3660_1130885631@jvdias>
This is a bug report for perl from jvdias(a)redhat.com,
generated with the help of perlbug 1.35 running under perl v5.8.7.
-----------------------------------------------------------------
[Please enter your report here]
When building perl-5.8.7 on Linux, the standard C headers fail to
be converted into perl headers, resulting in missing include
dependencies.
The C standard headers, such as :
stddef.h syslimits.h stdarg.h float.h stdbool.h
fail to be converted into perl headers (.ph files) during
a build and install of perl-5.8.7 . Many system headers
include these headers, so many system headers are made
unusable with perl because of this problem.
This is because h2ph's inc_dirs() does not find the string
'Reading specs from' in gcc -v's output, when the gcc version
is >= 4. My gcc's -v option emits:
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
$
gcc 4 understands the '-print-search-dirs' option:
$ gcc -print-search-dirs
install: /usr/lib/gcc/i386-redhat-linux/4.0.1/
...
Here's a patch which corrects h2ph.PL's inc_dirs() to pick up
gcc4's built-in header include path:
---
--- perl-5.8.7/utils/h2ph.PL.bz172236 2005-04-04 17:47:17.000000000 -0400
+++ perl-5.8.7/utils/h2ph.PL 2005-11-01 17:42:36.000000000 -0500
@@ -734,9 +734,15 @@
# non-GCC?) C compilers, but gcc uses an additional include directory.
sub inc_dirs
{
- my $from_gcc = `$Config{cc} -v 2>&1`;
- $from_gcc =~ s:^Reading specs from (.*?)/specs\b.*:$1/include:s;
-
+ my $from_gcc = `LC_ALL=C $Config{cc} -v 2>&1`;
+ if( !( $from_gcc =~ s:^Reading specs from (.*?)/specs\b.*:$1/include:s ) )
+ { # gcc-4+ :
+ $from_gcc = `LC_ALL=C $Config{cc} -print-search-dirs 2>&1`;
+ if ( !($from_gcc =~ s/^install:\s*([^\s]+[^\s\/])([\s\/]*).*$/$1\/include/s) )
+ {
+ $from_gcc = '';
+ };
+ };
length($from_gcc) ? ($from_gcc, $Config{usrinc}) : ($Config{usrinc});
}
---
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
This perlbug was built using Perl v5.8.7 in the Red Hat build system.
It is being executed now by Perl v5.8.7 - Tue Oct 25 19:39:19 EDT 2005.
Site configuration information for perl v5.8.7:
Configured by Red Hat, Inc. at Tue Oct 25 19:39:19 EDT 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=linux, osvers=2.6.13-1.1624_fc5, archname=i386-linux-thread-multi
uname='linux jvdias 2.6.13-1.1624_fc5 #1 mon oct 24 01:16:31 edt 2005 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -Dversion=5.8.7 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.6 5.8.5 5.8.4 5.8.3 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.0.2 20051007 (Red Hat 4.0.2-3)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.90.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.7/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.7:
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/5.8.7
.
---
Environment for perl v5.8.7:
HOME=/home/boston/jvdias
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/home/boston/jvdias/bin
PERL_BADLANG (unset)
SHELL=/bin/bash
18 years, 5 months
[PATCH] h2ph inc_dirs() fails to prepend gcc include search path, resulting in missing C standard headers on Linux
by Jason Vas Dias
To: perlbug(a)perl.org
Subject: h2ph inc_dirs fails to prepend gcc include search path, resulting in missing C standard headers on Linux
Reply-To: jvdias(a)redhat.com
Message-Id: <5.8.7_3660_1130885631@jvdias>
This is a bug report for perl from jvdias(a)redhat.com,
generated with the help of perlbug 1.35 running under perl v5.8.7.
-----------------------------------------------------------------
[Please enter your report here]
When building perl-5.8.7 on Linux, the standard C headers fail to
be converted into perl headers, resulting in missing include
dependencies.
The C standard headers, such as :
stddef.h syslimits.h stdarg.h float.h stdbool.h
fail to be converted into perl headers (.ph files) during
a build and install of perl-5.8.7 . Many system headers
include these headers, so many system headers are made
unusable with perl because of this problem.
This is because h2ph's inc_dirs() does not find the string
'Reading specs from' in gcc -v's output, when the gcc version
is >= 4. My gcc's -v option emits:
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
$
gcc 4 understands the '-print-search-dirs' option:
$ gcc -print-search-dirs
install: /usr/lib/gcc/i386-redhat-linux/4.0.1/
...
Here's a patch which corrects h2ph.PL's inc_dirs() to pick up
gcc4's built-in header include path:
---
--- perl-5.8.7/utils/h2ph.PL.bz172236 2005-04-04 17:47:17.000000000 -0400
+++ perl-5.8.7/utils/h2ph.PL 2005-11-01 17:42:36.000000000 -0500
@@ -734,9 +734,15 @@
# non-GCC?) C compilers, but gcc uses an additional include directory.
sub inc_dirs
{
- my $from_gcc = `$Config{cc} -v 2>&1`;
- $from_gcc =~ s:^Reading specs from (.*?)/specs\b.*:$1/include:s;
-
+ my $from_gcc = `LC_ALL=C $Config{cc} -v 2>&1`;
+ if( !( $from_gcc =~ s:^Reading specs from (.*?)/specs\b.*:$1/include:s ) )
+ { # gcc-4+ :
+ $from_gcc = `LC_ALL=C $Config{cc} -print-search-dirs 2>&1`;
+ if ( !($from_gcc =~ s/^install:\s*([^\s]+[^\s\/])([\s\/]*).*$/$1\/include/s) )
+ {
+ $from_gcc = '';
+ };
+ };
length($from_gcc) ? ($from_gcc, $Config{usrinc}) : ($Config{usrinc});
}
---
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
This perlbug was built using Perl v5.8.7 in the Red Hat build system.
It is being executed now by Perl v5.8.7 - Tue Oct 25 19:39:19 EDT 2005.
Site configuration information for perl v5.8.7:
Configured by Red Hat, Inc. at Tue Oct 25 19:39:19 EDT 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=linux, osvers=2.6.13-1.1624_fc5, archname=i386-linux-thread-multi
uname='linux jvdias 2.6.13-1.1624_fc5 #1 mon oct 24 01:16:31 edt 2005 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -Dversion=5.8.7 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.6 5.8.5 5.8.4 5.8.3 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.0.2 20051007 (Red Hat 4.0.2-3)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.90.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.7/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.7:
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/5.8.7
.
---
Environment for perl v5.8.7:
HOME=/home/boston/jvdias
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/home/boston/jvdias/bin
PERL_BADLANG (unset)
SHELL=/bin/bash
18 years, 5 months
[Bug 71513] perl headers are incompletely built
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: perl headers are incompletely built
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71513
wtogami(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |CLOSED
Resolution| |DUPLICATE
------- Additional Comments From wtogami(a)redhat.com 2005-11-01 15:34 EST -------
Closing as duplicate against a more coherent explanation of this problem.
*** This bug has been marked as a duplicate of 172236 ***
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 5 months