Re: [perl #36354] Test::More [0.60]: eq_set has a broken sort logic
On Sat, Jul 02, 2005 at 09:50:38PM -0700, Michael G Schwern wrote: > Neither of these works fully, though they do no worse than the existing code. I take that back. Because it attempts to sort the references it breaks the previously working case where the references were already in order. So I instead just don't sort the references at all which is effectively what the original did. return eq_array( [grep(ref, @$a1), sort( grep(!ref, @$a1) )], [grep(ref, @$a2), sort( grep(!ref, @$a2) )], ); -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [perl #36354] Test::More [0.60]: eq_set has a broken sort logic
On Thu, Jun 23, 2005 at 12:32:43AM +0200, Abigail wrote:
> > If the purpose is merely to provide a *consistent* sorting, this will
> > suffice:
> >
> > sort { (ref $a) cmp (ref $b) or$a cmp $b } @$a1
>sort (grep {ref} @$a1), sort (grep {!ref} @$a1)
Neither of these works fully, though they do no worse than the existing code.
Here's the two test cases:
my $ref = \2;
ok( eq_set( [$ref, "$ref", "$ref", $ref],
["$ref", $ref, $ref, "$ref"]
) );
ok( eq_set( [\1, \2, \3], [\3, \2, \1] ) );
The first works, the second does not. In the second the arrays are left
in the same order by the sorts. This is because its sorting based on the
reference, not the contents of the reference. As the function is
discouraged I'm not going to put in the effort to repair it. But I will
repair the sort function as recommended so that its at least consistent.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- "Witches Abroad" by Terry Prachett
Smoke [5.9.3] 25055 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
Automated smoke report for 5.9.3 patch 25055 TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu) onMSWin32 - WinXP/.Net SP1 using cl version 12.00.8804 smoketime 4 hours 13 minutes (average 10 minutes 35 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25055 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - M M M M -Dusemymalloc M M -Duselargefiles M M -Duselargefiles -Dusemymalloc M M -Duseithreads M M -Duseithreads -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' M M -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [minitest] [minitest] -DDEBUGGING [minitest] -Dusemymalloc [minitest] -DDEBUGGING -Dusemymalloc [minitest] -Duselargefiles [minitest] -DDEBUGGING -Duselargefiles [minitest] -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/inplaceFAILED tests 1-2 io/iprefixFAILED tests 1-2 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 [minitest] -Duseithreads [minitest] -DDEBUGGING -Duseithreads [minitest] -Duseithreads -Duselargefiles [minitest] -DDEBUGGING -Duseithreads -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/inplaceFAILED tests 1-2 io/iprefixFAILED tests 1-2 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/fork...FAILED tests 1-19 op/threadsdubious DIED. FAILED tests 1-3 -- Report by Test::Smoke v1.19_70 build 861 running on perl 5.8.7 (Reporter v0.021 / Smoker v0.024) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Building 5.004_05 on OS X
I'm trying to build 5.4.5 on OS X so I can have a 5.4.x to test modules against. I set -Dso=dylib so it can find shared libs. The hurdle after that was getting around the fact that it tries to make both 'makefile' and 'Makefile' and gets confused. Setting -Dfirstmakefile="First_Makefile" to disambiguate gets things going. Configure completes, make depend runs and then make gets up to x2p which complains "You haven't run a "make depend""! makedepend does run and does appear to be going into the x2p directory and says its looking for dependencies in all the necessary files in there but no .o files result. I altered makedepend so it didn't delete .deptmp and it seems to be finding dependencies. At which point I'm lost. Anyone have an idea what to do next to move the build along? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
ignoring close failures
This bit of Perl_sv_clear is generating a compiler warning now:
case SVt_PVIO:
if (IoIFP(sv) &&
IoIFP(sv) != PerlIO_stdin() &&
IoIFP(sv) != PerlIO_stdout() &&
IoIFP(sv) != PerlIO_stderr())
{
io_close((IO*)sv, FALSE);
}
Should we really be ignoring close failure here? Would it be better to
issue a lexical warning? If so, what category? And what text?
Nicholas Clark
Re: [PATCH] no Carp #8 - SelfLoader, Text/Balanced and open.pm
On 7/2/05, Dave Mitchell <[EMAIL PROTECTED]> wrote: > > I've applied those of your Carp patches that don't effect dual-homed > modules (as determined by 'CPAN' => 1 in Porting/Maintainers.pl). > Since it isn't fixing critial bugs, I'm assuming its up to the authors > to decide. Thanks, that's what I was about to do. Anyway, for non-dual modules, I don't think it's necessary to set alpha-style versions numbers, you can directly increment them.
destructors and IOs
Blessed file handles aren't counted by PL_sv_objcount
This seems to be by design, as it's all quite explicit in the source. The
upshot is that if you attempt to avoid "unnecessary" work during destruction:
//depot/perl/sv.c#946 - /home/nick/p4perl/perl/sv.c
--- /tmp/tmp.7324.0 Sat Jul 2 20:14:56 2005
+++ /home/nick/p4perl/perl/sv.c Sat Jul 2 18:52:57 2005
@@ -494,8 +494,10 @@ Perl_sv_clean_objs(pTHX)
PL_in_clean_objs = TRUE;
visit(do_clean_objs, SVf_ROK, SVf_ROK);
#ifndef DISABLE_DESTRUCTOR_KLUDGE
-/* some barnacles may yet remain, clinging to typeglobs */
-visit(do_clean_named_objs, SVt_PVGV, SVTYPEMASK);
+if (PL_sv_objcount) {
+ /* some barnacles may yet remain, clinging to typeglobs */
+ visit(do_clean_named_objs, SVt_PVGV, SVTYPEMASK);
+}
#endif
PL_in_clean_objs = FALSE;
}
then tests fail:
op/ref.t 891 1.12% 71
run/fresh_perl.t 941 1.06% 53
Notably both these tests have their own little hacks to ensure that the
destructor gets called at all:
op/ref.t test 71:
# using a regex in the destructor for STDOUT segfaulted because the
# REGEX pad had already been freed (ithreads build only). The
# object is required to trigger the early freeing of GV refs to to STDOUT
like (runperl(
prog => '$x=bless[]; sub IO::Handle::DESTROY{$_="bad";s/bad/ok/;print}',
stderr => 1
), qr/^(ok)+$/, 'STDOUT destructor');
run/fresh_perl.t test 53:
package X;
sub any { bless {} }
my $f = "FH000"; # just to thwart any future optimisations
sub afh { select select ++$f; my $r = *{$f}{IO}; delete $X::{$f}; bless $r }
sub DESTROY { print "destroyed\n" }
package main;
$x = any X; # to bump sv_objcount. IO objs aren't counted??
*f = afh X;
EXPECT
destroyed
destroyed
Isn't the current behaviour a bit of a bodge? Why is it this way?
Nicholas Clark
Re: [perl #36427] With long chains of references both Storable and Data::Dumper cause perl to fail
On Wed, Jun 29, 2005 at 09:46:33PM -, kynn jones wrote: > With an argument greater than some system-dependent critical size, the > script causes perl to segfault: > > use strict; > use warnings; > > my $size = shift; > > my $x = []; > $x = [ $x ] for 1..$size; > > require Storable; > Storable::store( \$x, '/tmp/$0.$$' ) or die; It's the stack being trashed due to excessive recursion. No real way to fix it short of rewriting Storable to be iterative rather than recursive. The workaround is to increase the stack size available to the process with 'uname -s' -- In defeat, indomitable; in victory, insufferable -- Churchill on Montgomery
Re: Date::Parse (Time::Local?) choking on years between 1956<->1938 and wrong below, on FC4/5.8.6
On Fri, Jul 01, 2005 at 05:12:41PM -0400, Scott R. Godin wrote:
> 5:10pm {638} localhost:/home/webadmin/>$ cat mydate
> #!/usr/bin/perl -l
> use Date::Parse qw/str2time/;
> my $d = $ARGV[0];
> my $utime = str2time("01/01/$d");
> print "$utime\t", scalar localtime $utime;
>
> 5:10pm {639} localhost:/home/webadmin/>$ ./mydate 1956
> -441831600 Sun Jan 1 00:00:00 1956
Times on UNIX are usually stored as seconds since 1970, so library
functions which deal with times as numbers are unlikely to correctly
handle dates before 1970 (or after 2037 for 32-bit systems).
--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
-- Monty Python - "Finland"
Re: [perl #36450] Lvalue sub fails under debugger
On Sat, Jul 02, 2005 at 10:03:42AM -, houstorx @ rpc142. cs. man. ac. uk
wrote:
> Lvalue functions don't work properly when running under the
> debugger (perl -d). For example, the following code:
>
> my $x = 'badbad';
> sub x :lvalue {$x}
> x = "good";
> print "The value of \$x is: $x\n";
>
> prints 'The value of $x is: badbad' when you run it with the
> debugger. This happens with every version of perl that I've
> tested, including 5.8.6 and 5.9.2.
The reason is that when running under the debugger, all function calls are
wrapped by a call to BD::sub, which does (in outline)
if (wantarray)
@res = &$sub;
...
@res;
}
else {
$res = &$sub;
...
$res;
}
and of course that blows away the lvalue-ness of the value returned by the
sub.
Can't see an easy way op fixing it.
--
Fire extinguisher (n) a device for holding open fire doors.
Re: [PATCH] no Carp #8 - SelfLoader, Text/Balanced and open.pm
I've applied those of your Carp patches that don't effect dual-homed modules (as determined by 'CPAN' => 1 in Porting/Maintainers.pl). Since it isn't fixing critial bugs, I'm assuming its up to the authors to decide. (And I've finally been won round to the idea that it's worthwhile avoiding use Carp in small, common modules). Change #25052 not applied: Subject: [PATCH] Make Time::Local to load Carp only when nec. Subject: [PATCH] Put Carp into the Tarpit (No Carp #2 - Archive::Tar) Subject: [PATCH] no Carp! #3 - Attribute::Handlers applied: Subject: [PATCH] No Carp #4 AutoSplit.pm Subject: [PATCH] no Carp #5 (File::Path) Subject: [PATCH] no Carp #7 - charnames.pm partly appplied: Subject: [PATCH] no Carp #6 (File::Compare, File::Copy, File::Temp) except File::Temp Subject: [PATCH] no Carp #8 - SelfLoader, Text/Balanced and open.pm except Text/Balanced Dave. -- The Enterprise is involved in a bizarre time-warp experience which is in some way unconnected with the Late 20th Century. -- Things That Never Happen in "Star Trek" #14
Re: demacroize ckWARN*
On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote: > If I remember right, a lot of code tests whether the warning is enabled > before testing whether the warning case applies, on the assumption that > the first check is quick. Many of those cases may want to be re-evaluated > in the light of this patch. I was going to save that for another day :-) -- To collect all the latest movies, simply place an unprotected ftp server on the Internet, and wait for the disk to fill
Re: demacroize ckWARN*
Dave Mitchell <[EMAIL PROTECTED]> wrote: :The various macros ckWARN* are big and clunky, and are used about 600 :times in the core. Since they are usually evaluated only in 'this :shouldn't be happening' codepaths, there doesn't seem to be any benefit :in avoiding a function call. "This shouldn't be happening" would normally be true for code that has the relevant warning enabled, but may not be for code that doesn't. :The patch below adds functions to do the bulk of the macros, and reduces :the size of the perl executable by 2% (!), and according to make test, is :fractionally faster (but that is most likely noise). If I remember right, a lot of code tests whether the warning is enabled before testing whether the warning case applies, on the assumption that the first check is quick. Many of those cases may want to be re-evaluated in the light of this patch. Hugo
demacroize ckWARN*
The various macros ckWARN* are big and clunky, and are used about 600
times in the core. Since they are usually evaluated only in 'this
shouldn't be happening' codepaths, there doesn't seem to be any benefit
in avoiding a function call.
The patch below adds functions to do the bulk of the macros, and reduces
the size of the perl executable by 2% (!), and according to make test, is
fractionally faster (but that is most likely noise).
Dave.
--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
(with apologies to William Blake)
Change 25050 by [EMAIL PROTECTED] on 2005/07/02 15:05:04
replace ckWARN macros with functions
Affected files ...
... //depot/perl/embed.fnc#218 edit
... //depot/perl/embed.h#496 edit
... //depot/perl/pod/perlintern.pod#42 edit
... //depot/perl/proto.h#569 edit
... //depot/perl/util.c#477 edit
... //depot/perl/warnings.h#26 edit
... //depot/perl/warnings.pl#47 edit
Differences ...
//depot/perl/embed.fnc#218 (text)
@@ -1524,6 +1524,8 @@
#ifdef PERL_DONT_CREATE_GVSV
Ap |GV*|gv_SVadd |NN GV* gv
#endif
+po |bool |ckwarn |U32 w
+po |bool |ckwarn_d |U32 w
p |void |offer_nice_chunk |NN void *chunk|U32 chunk_size
//depot/perl/embed.h#496 (text+w)
@@ -3619,6 +3619,8 @@
#define gv_SVadd(a)Perl_gv_SVadd(aTHX_ a)
#endif
#ifdef PERL_CORE
+#endif
+#ifdef PERL_CORE
#define offer_nice_chunk(a,b) Perl_offer_nice_chunk(aTHX_ a,b)
#endif
#define ck_anoncode(a) Perl_ck_anoncode(aTHX_ a)
//depot/perl/pod/perlintern.pod#42 (text+w)
@@ -224,7 +224,12 @@
=item PAD_SET_CUR
Set the current pad to be pad C in the padlist, saving
-the previous current pad.
+the previous current pad. NB currently this macro expands to a string too
+long for some compilers, so it's best to replace it with
+
+SAVECOMPPAD();
+PAD_SET_CUR_NOSAVE(padlist,n);
+
voidPAD_SET_CUR (PADLIST padlist, I32 n)
//depot/perl/proto.h#569 (text+w)
@@ -2995,6 +2995,8 @@
__attribute__nonnull__(pTHX_1);
#endif
+PERL_CALLCONV bool Perl_ckwarn(pTHX_ U32 w);
+PERL_CALLCONV bool Perl_ckwarn_d(pTHX_ U32 w);
PERL_CALLCONV void Perl_offer_nice_chunk(pTHX_ void *chunk, U32 chunk_size)
__attribute__nonnull__(pTHX_1);
//depot/perl/util.c#477 (text)
@@ -1376,6 +1376,58 @@
}
}
+/* implements the ckWARN? macros */
+
+bool
+Perl_ckwarn(pTHX_ U32 w)
+{
+return
+ (
+ isLEXWARN_on
+ && PL_curcop->cop_warnings != pWARN_NONE
+ && (
+ PL_curcop->cop_warnings == pWARN_ALL
+ || isWARN_on(PL_curcop->cop_warnings, unpackWARN1(w))
+ || (unpackWARN2(w) &&
+isWARN_on(PL_curcop->cop_warnings, unpackWARN2(w)))
+ || (unpackWARN3(w) &&
+isWARN_on(PL_curcop->cop_warnings, unpackWARN3(w)))
+ || (unpackWARN4(w) &&
+isWARN_on(PL_curcop->cop_warnings, unpackWARN4(w)))
+ )
+ )
+ ||
+ (
+ isLEXWARN_off && PL_dowarn & G_WARN_ON
+ )
+ ;
+}
+
+/* implements the ckWARN?_d macro */
+
+bool
+Perl_ckwarn_d(pTHX_ U32 w)
+{
+return
+ isLEXWARN_off
+ || PL_curcop->cop_warnings == pWARN_ALL
+ || (
+ PL_curcop->cop_warnings != pWARN_NONE
+ && (
+ isWARN_on(PL_curcop->cop_warnings, unpackWARN1(w))
+ || (unpackWARN2(w) &&
+ isWARN_on(PL_curcop->cop_warnings, unpackWARN2(w)))
+ || (unpackWARN3(w) &&
+ isWARN_on(PL_curcop->cop_warnings, unpackWARN3(w)))
+ || (unpackWARN4(w) &&
+ isWARN_on(PL_curcop->cop_warnings, unpackWARN4(w)))
+ )
+ )
+ ;
+}
+
+
+
/* since we've already done strlen() for both nam and val
* we can use that info to make things faster than
* sprintf(s, "%s=%s", nam, val)
//depot/perl/warnings.h#26 (text+w)
@@ -88,61 +88,15 @@
#define isWARN_on(c,x) (IsSet(SvPVX_const(c), 2*(x)))
#define isWARNf_on(c,x)(IsSet(SvPVX_const(c), 2*(x)+1))
-#define ckWARN(x) \
- ( (isLEXWARN_on && PL_curcop->cop_warnings != pWARN_NONE && \
- (PL_curcop->cop_warnings == pWARN_ALL || \
- isWARN_on(PL_curcop->cop_warnings, x) ) )\
- || (isLEXWARN_off && PL_dowarn & G_WARN_ON) )
+#define ckWARN(w) Perl_ckwarn(aTHX_ packWARN(w))
+#define ckWARN2(w1,w2) Perl_ckwarn(aTHX_ packWARN2(w1,w2))
+#define ckWARN3(w1,w2,w3) Perl_ckwarn(aTHX_ packWARN3(w1,w2,w3))
+#define ckWARN4(w1,w2,w3,w4) Perl_ckwarn(aTHX_ packWARN4(w1,w2,w3,w4))
-#define ckWARN2(x,y) \
- ( (isLEXW
Smoke [5.9.3] 25043 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25043 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 56 minutes (average 1 hour 58 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25043 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
[perl #36450] Lvalue sub fails under debugger
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36450]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36450 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
Lvalue functions don't work properly when running under the
debugger (perl -d). For example, the following code:
my $x = 'badbad';
sub x :lvalue {$x}
x = "good";
print "The value of \$x is: $x\n";
prints 'The value of $x is: badbad' when you run it with the
debugger. This happens with every version of perl that I've
tested, including 5.8.6 and 5.9.2.
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.6:
Configured by houstorx at Wed Jun 29 10:53:40 BST 2005.
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.4.20-31.9, archname=i686-linux
uname='linux rpc142 2.4.20-31.9 #1 tue apr 13 17:38:16 edt 2004 i686 athlon
i386 gnulinux '
config_args='-Dprefix=/local/perl -Doptimize=-g -ders'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -I/opt/gnu/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-g',
cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include
-I/opt/gnu/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)',
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='cc', ldflags =' -L/usr/local/lib -L/opt/gnu/lib'
libpth=/usr/local/lib /opt/gnu/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib -L/opt/gnu/lib'
Locally applied patches:
---
@INC for perl v5.8.6:
/local/perl/lib/5.8.6/i686-linux
/local/perl/lib/5.8.6
/local/perl/lib/site_perl/5.8.6/i686-linux
/local/perl/lib/site_perl/5.8.6
/local/perl/lib/site_perl
.
---
Environment for perl v5.8.6:
HOME=/home/X02/houstorx
LANG=en_GB
LANGUAGE (unset)
LC_COLLATE=C
LD_LIBRARY_PATH=/lib:/usr/lib:/opt/sfw/lib:/opt/gnu/lib:/home/X02/houstorx/lib
LOGDIR (unset)
PATH=/local/bin:/local/Acrobat5/bin:/usr/ucb:/opt/perl-5.8/sun4-solaris-64int/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/opt/common/bin:/usr/sbin:/home/X02/houstorx/bin:/opt/prolog/bin:/opt/pl-4.0.9/bin:/opt/teaching/bin:/opt/sfw/bin:/opt/cs/bin:/usr/ccs/bin:/opt/gnu/bin
PERL_BADLANG (unset)
SHELL=/bin/bash
Vacations
Starting tomorrow, I'm in vacation for two weeks. I'll be reading my @gmail.com mail intermittently, (probably not the other ones), and might be able to commit stuff, but I'd appreciate if the current patches are applied by other commiters, since I don't want to be overwhelmed by exploding mailboxes at my return.
