RE: [ID 19991001.005] [_61] tarball fine on win32, zip isn't
> >If somebody on Win* platforms (who cares enough to demand a .zip in > >the first place) could produce a script that in a UNIX box automagically > >converts a latest.tar.gz into a 8.3-friendly .zip, I would be very glad. > I have to admit that I don't really see the point of providing a zip file > at all. People trying to compile Perl themselves shouldn't have any > problems processing tarballs. > I vote for this point of view. At least cygwin will help to unzip and untar. > But in any case, doesn't > > zip -ro9 devel perl5.005_61 > > create the correct thing? > -zip -ro9 devel perl5.005_61 +zip -Ro9 devel perl5.005_61 :) If I understand correctly -R stands for 'Recurse subdirectories' and is upcase letter. Good luck, Vadim.
[PATCH 5.005_61 DOC] misprint in perguts
(I think this misprint is obvious) --- perlguts.pod.oldWed Oct 13 14:53:07 1999 +++ perlguts.podWed Oct 13 14:53:18 1999 @@ -2906,11 +2906,11 @@ =item strnEQ Test two strings to see if they are equal. The C parameter indicates the number of bytes to compare. Returns true or false. - int strnEQ( char *s1, char *s2 ) + int strnEQ( char *s1, char *s2, int len ) =item strnNE Test two strings to see if they are different. The C parameter indicates the number of bytes to compare. Returns true or false.
else{die} reports incorrect line number
Following script:
if (0) {}
else {die
}
reports:
Died at xr line 1.
whereas following script:
if (0) {}
else {
die
}
reports:
Died at xr line 3.
Both installed on my machine 5.005_03 and 5.6.0 produce same output.
I think this is less than a bug but is bigger than microbe.
&Vadim;
Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-object
uname=''
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cl.exe', optimize='-Od -MD -DNDEBUG -TP -GX', gccversion=
cppflags='-DWIN32'
ccflags ='-Od -MD -DNDEBUG -TP -GX -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT -DPERL_OBJECT'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -release
-libpath:"C:\Perl\ActivePerl\lib\CORE" -machine:x86'
libpth="C:\Perl\ActivePerl\lib\CORE" "C:\MSVStudio\VC98\mfc\lib"
"C:\MSVStudio\VC98\lib"
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
PerlCRT.lib
libc=C:\Perl\ActivePerl\lib\CORE\PerlCRT.lib, so=dll, useshrplib=yes,
libperl=perlcore.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-libpath:"C:\Perl\ActivePerl\lib\CORE" -machine:x86'
Characteristics of this binary (from libperl):
Locally applied patches:
ActivePerl Build 522
Built under MSWin32
Compiled at Nov 2 1999 09:52:28
%ENV:
PERL5LIB="D:\Work\PerlScripts\sgml;D:\Work\PerlScripts\translations;D:\Work\
PerlScripts\pleps;D:\Work\PerlScripts\utl"
@INC:
D:\Work\PerlScripts\sgml
D:\Work\PerlScripts\translations
D:\Work\PerlScripts\pleps
D:\Work\PerlScripts\utl
c:/perl/ActivePerl/lib
c:/perl/ActivePerl/site/lib
.
Summary of my perl5 (revision 5 version 6 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=undef
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='bcc32', optimize='-O2 -D_RTLDLL', gccversion=
cppflags='-DWIN32'
ccflags ='-O2 -D_RTLDLL -DWIN32 -D_MT -D__USELOCALES__
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_ITHREADS'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='ilink32', ldflags ='-x -Gn
-L"D:\perl\lib\MSWin32-x86-multi-thread\CORE"
-L"c:\borland\CBuilder5\lib" -L"c:\borland\CBuilder5\lib\Release"
-L"c:\borland\CBuilder5\lib\Obj"'
libpth=c:\borland\CBuilder5\lib c:\borland\CBuilder5\lib\Release
c:\borland\CBuilder5\lib\obj
libs= import32.lib cp32mti.lib vcl.lib vcl50.lib vcle50.lib vclx50.lib
vcldb50.lib vcldbx50.lib
libc=cp32mti.lib vcl.lib vcl50.lib vcle50.lib vclx50.lib vcldb50.lib
vcldbx50.lib, so=dll, useshrplib=yes, libperl=perl56.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags='-tWD'
cccdlflags=' ', lddlflags='-Tpd -x -Gn
-L"D:\perl\lib\MSWin32-x86-multi-thread\CORE"
-L"c:\borland\CBuilder5\lib" -L"c:\borland\CBuilder5\lib\Release"
-L"c:\borland\CBuilder5\lib\Obj"'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT
PERL_IMPLICIT_SYS
Locally applied patches:
ActivePerl Build 618
Built under MSWin32
Compiled at Oct 19 2000 00:18:20
%ENV:
PERL5LIB="D:\Work\PerlScripts\sgml;D:\Work\PerlScripts\translations;D:\Work\
PerlScripts\pleps;D:\Work\PerlScripts\utl"
@INC:
D:\Work\PerlScripts\sgml
D:\Work\PerlScripts\translations
D:\Work\PerlScripts\pleps
D:\Work\PerlScripts\utl
D:/perl/lib/MSWin32-x86-multi-thread
D:/perl/lib
D:/perl/site/lib/MSWin32-x86-multi-thread
D:/perl/site/lib
.
RE: fix for win32/buildext.pl
> >> > my $make = shift; > >> > my $dep = shift; > >> > my $dir = shift; > >> > > >> >works not as expected on my system because it's called > >> >as "dmake -S [argumentarios]" > >> > >> It might be better to patch makefile.mk to "quote" $(MAKE), > >> what does the -S do (I just treat dmake like Unix make and hope > >> for the best.) > Still does not answer what -S does - should we keep it and pass > to sub-make ? readme.txt for dmake reads: -S Force sequential execution of recipes on architec- tures which support concurrent makes. For backward compatibility with old makefiles that have nasty side-effect prerequisite dependencies. I'm not able to understand this explanation, and it's easier for me to live without it. > >BTW why GNU make is not used? because of GPL? > > There wasn't a VC++/Mingw32 port of GNU make when we started, > and cygwin was unstable. Ok, I understand this now. It seems to me that dmake have more limitations as compared to "make", isn't it time to migrate to it now? Best wishes, &Vadim;
RE: t/lib/u-* tests
> > My build of perl@9762 fails with all t/lib/u-* tests: [snip] > > What I'm misunderstanding here? > > > > How to fix it? > > > > I use BorlandC++ builder on Win32 platform. > > The BorlandC++ builder might have something to do with the problem > you had. I note this in the README.win32 file in the main directory > of the distribution: > > =item Borland C++ > > If you are using the Borland compiler, you will need dmake. > (The make that Borland supplies is seriously crippled and will not > work for MakeMaker builds.) > > Hence you are recommended to switch to dmake and use the > win32\makefile.mk > Note that the latter file has the following rule in it: > > Extensions : buildext.pl $(PERLDEP) $(CONFIGPM) > $(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP) $(EXTDIR) > > which ought to take care of building ext\List\Util\* for you. I do use dmake, and did so a zillion number of times. Until recently (until introduction of those u-* tests?) all was okay. I think those test were not correctly introduced into win32/makefile.mk Okay, I'll dig it at evening later today... Best wishes &Vadim;
BCC for Win32 is unhappy @14331
Hello, all! I hope this is correct fix, if not - please do not apply it. BCC explains about incorrect numeric operation for some reason ... diff -u -r perl@14331-orig/hv.h perl@14331/hv.h --- perl@14331-orig/hv.hThu Jan 3 08:54:58 2002 +++ perl@14331/hv.h Sun Jan 20 23:40:40 2002 @@ -145,7 +145,7 @@ #define XHvPLACEHOLDERS(xhv) ((xhv)->xhv_placeholders) /* the number of keys that exist() (i.e. excluding placeholers) */ -#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - XHvPLACEHOLDERS(xhv)) +#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - (int)XHvPLACEHOLDERS(xhv)) /* * HvKEYS gets the number of keys that actually exist(), and is provided Best wishes, Vadim.
RE: BCC for Win32 is unhappy @14331
> Hello, all! > > I hope this is correct fix, if not - please do not apply it. > BCC explains about incorrect numeric operation for some reason ... > > diff -u -r perl@14331-orig/hv.h perl@14331/hv.h > --- perl@14331-orig/hv.h Thu Jan 3 08:54:58 2002 > +++ perl@14331/hv.h Sun Jan 20 23:40:40 2002 > @@ -145,7 +145,7 @@ > #define XHvPLACEHOLDERS(xhv) ((xhv)->xhv_placeholders) > > /* the number of keys that exist() (i.e. excluding placeholers) */ > -#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - > XHvPLACEHOLDERS(xhv)) stupid mailer! please see attached text file... > +#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - > (int)XHvPLACEHOLDERS(xhv)) > > /* > * HvKEYS gets the number of keys that actually exist(), and > is provided > > > > Best wishes, > Vadim. > diff -u -r perl@14331-orig/hv.h perl@14331/hv.h --- perl@14331-orig/hv.hThu Jan 3 08:54:58 2002 +++ perl@14331/hv.h Sun Jan 20 23:40:40 2002 @@ -145,7 +145,7 @@ #define XHvPLACEHOLDERS(xhv) ((xhv)->xhv_placeholders) /* the number of keys that exist() (i.e. excluding placeholers) */ -#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - XHvPLACEHOLDERS(xhv)) +#define XHvUSEDKEYS(xhv) (XHvTOTALKEYS(xhv) - (int)XHvPLACEHOLDERS(xhv)) /* * HvKEYS gets the number of keys that actually exist(), and is provided
RE: [ID 20020214.002] inf/inf yields wrong answer with Math::BigInt 1.49
> IEEE 754 also says that inf-inf = NaN and inf - (-inf) = NaN. I agree with all discussed operations with 'inf' but the last one. I think it should be inf - (-inf) = inf because inf+inf=inf Do you mean inf + (-inf) = NaN ? Vadim.
RE: [PATCH] good day for WinCE port of perl.
> > Are you in doubt only for ./ext/Encode/CN/Makefile.PL or > you're in doubt for > > a whole family of those changes? We can temporarily exclude > building of > > The whole family of those changes. > > I'm having doubts because having to modify several Makefile.PL's of an > extension that is completely unrelated to cross-compilation doesn't > feel right. Such need for modifications doesn't bode well for future: > how many other extensions will we have to moodify because of > cross-compilation? Just because I tried those recently, I can tell you it is the only place in perl distribution. May be sometimes undependent extensions will not build with -MCross option, but mostly they should. (currently -MCross for MakeMaker works only for CORE=1, but this is not very hard to implement it further) > It feels like the logic should be somewhere > higher up (e.g. MakeMaker?). I see your point. But in this case the script Makefile.PL itself has logic which tries to construct command line without thinking of some alien possibilities, in our case it does not worries about -MCross. And in more common and general cases, like for other extensions, -MCross already works okay. If you'll invent a function ExtUtils::MM_Unix::special_arguments() that will emit needed additional options for unusual cases, who will guarantee that next time module author will use it at proper time? Anyway, I thought about those changes as harmless, but if it is not the case, let's skip them! (It is pitty that Encode:: will not be that easily available for WinCE then, but I think there are many things to do outside that problem anyway) Best wishes, Vadim.
[PATCH@23361] RE: [PATCH-for-23358] enable statically linked exte nsions for Win32
> > I did modifications so my patch should fit 592.
> >
>
> Thanks, applied to bleadperl as change #23360.
Thanks,
attached is continuation of previous one.
it also makes win32/Makefile and win32/makefile.mk closer.
Best regards,
Vadim.
diff -r -u bperl-current-orig/win32/buildext.pl
bperl-current1-for-diff/win32/buildext.pl
--- bperl-current-orig/win32/buildext.plTue Oct 12 17:26:54 2004
+++ bperl-current1-for-diff/win32/buildext.pl Wed Oct 13 09:28:07 2004
@@ -60,7 +60,13 @@
print $fh "#ifdef STATIC3\n",(map {"newXS(\"$statics2[$_]::bootstrap\",
boot_$statics1[$_], file);\n"} 0 .. $#statics),"#undef STATIC3\n#endif\n";
}
else {
-print map {/([^\/]+)$/;"$_/$1.lib "} @statics;
+my %extralibs;
+for (@statics) {
+ open my $fh, "<..\\lib\\auto\\$_\\extralibs.ld" or die "can't open
<..\\lib\\auto\\$_\\extralibs.ld: $!";
+ $extralibs{$_}++ for grep {/\S/} split /\s+/, join '', <$fh>;
+}
+print map {/([^\/]+)$/;"..\\lib\\auto\\$_/$1.lib "} @statics;
+print map {"$_ "} sort keys %extralibs;
}
exit;
}
diff -r -u bperl-current-orig/win32/makefile.mk
bperl-current1-for-diff/win32/makefile.mk
--- bperl-current-orig/win32/makefile.mkTue Oct 12 17:26:54 2004
+++ bperl-current1-for-diff/win32/makefile.mk Wed Oct 13 09:39:54 2004
@@ -155,7 +155,14 @@
# extensions if you change the default. Currently, this cannot be enabled
# if you ask for USE_IMP_SYS above.
#
-#PERL_MALLOC *= define
+PERL_MALLOC*= define
+
+#
+# set this to enable debugging mstats
+# This must be enabled to use the Devel::Peek::mstat() function. This cannot
+# be enabled without PERL_MALLOC as well.
+#
+DEBUG_MSTATS = define
#
# set the install locations of the compiler include/libraries
@@ -239,6 +246,19 @@
USE_LARGE_FILES*= undef
USE_PERLCRT*= undef
+.IF "$(PERL_MALLOC)" == "undef"
+PERL_MALLOC= undef
+DEBUG_MSTATS = undef
+.ENDIF
+
+.IF "$(DEBUG_MSTATS)" == "undef"
+DEBUG_MSTATS = undef
+.ENDIF
+
+.IF "$(DEBUG_MSTATS)" == "define"
+BUILDOPT += -DPERL_DEBUGGING_MSTATS
+.ENDIF
+
.IF "$(USE_IMP_SYS)$(USE_MULTI)" == "defineundef"
USE_MULTI != define
.ENDIF
@@ -1035,10 +1055,9 @@
perl.exp $(LKPOST))
.ELSE
$(LINK32) -dll -def:perldll.def -out:$@ \
- -base:0x2800 $(BLINK_FLAGS) $(DELAYLOAD) $(LIBFILES) \
- $(foreach,i,$(shell $(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP)
ext --list-static-libs) \
- ..\lib\auto\$i) \
- $(PERLDLL_RES) $(PERLDLL_OBJ:s,\,\\)
+ $(shell $(MINIPERL) -I..\lib buildext.pl --list-static-libs) \
+ @$(mktmp -base:0x2800 $(BLINK_FLAGS) $(DELAYLOAD) $(LIBFILES) \
+ $(PERLDLL_RES) $(PERLDLL_OBJ:s,\,\\))
.ENDIF
$(XCOPY) $(PERLIMPLIB) $(COREDIR)
@@ -1121,7 +1140,7 @@
$(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP) $(EXTDIR) --dynamic
$(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP) ext --dynamic
-Extensions_static : buildext.pl $(PERLDEP) $(CONFIGPM)
+Extensions_static : buildext.pl
$(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP) ext --static
$(MINIPERL) -I..\lib buildext.pl $(MAKE) $(PERLDEP) $(EXTDIR) --static
RE: [perl #31973] Re: "perl 5.8.2 (on Power PC) Can't locate lib .pm - ?" - who is responsible for Power PC perl 5.8.5 port ?
> So I have ONLY two alternatives: > > 1) Somehow "fix" installed power pc perl 5.8.2 - by adding > "missing" or > "misplaced" 5.8.2 perl module files > (such as lib.pm, Config.pm, etc. ) Although generally you need to make proper installation, in this particular case you could just get things working. First, tell us how you get that perl-5.8.2 You tried to build 5.8.5, but then switched to 582. Is it already-built binaries? Is it from some Linux distribution? If this is the case, usually it's not hard to make it just work. Mostly you place your files properly, edit Config.pm, and all should be working. You can send binaries directly to me and I can try figuring this out. > 2) build 5.8.5 natively - who is responsible for Power PC > perl 5.8.5 port ? I don't see binaries at binaries/ports page for PowerPC at http://www.cpan.org/ports/ This page is somehow outdated however.
RE: [perl #31973] Re: "perl 5.8.2 (on Power PC) Can't locate lib .pm - ?" - who is responsible for Power PC perl 5.8.5 port ?
> perl-5.8.2 - came as pre-built binaries - from "free"
> Arabella (partner of
> Motorola/Freescale) CD-ROM (came with the board) - without support and
> without any documentation (fadsroot). I copied it ("fadsroot
> directory" from
> that CD-ROM onto the disk drive of my Linux Red Hat 9 Shrike
> Intel PC (NFS
> server) and my board mounts it as root file system during the booting
> (this is the intended use of "fadsroot").
ok. let us think those are valid binaries until proven otherwise.
> Apparently there were also some "remnants" of 5.8.0 ...
let use hope those do not mess with your binaries, unless...
> >You can send binaries directly to me and I can try figuring this out
>
> This is "scattered" across several directories - should I
> tar/zip all those
> and send to you (how ? - may be more than
> e-mail could handle).
send them by archive to my home address [EMAIL PROTECTED] , and do NOT CC
to p5p list.
I hope that e-mail is reachable for you, lemme know otherwise.
>
> So there is no "designated porter" dealing with perl on Power
> PC arch ?
AFAIK people contribute their efforts as they do, no special designated
porters.
Personally, I have some little experience on running perl on PPC, but I
haven't got so far to rebuild recent perl for it.
Best regards,
Vadim.
RE: [perl #31973] Re: "perl 5.8.2 (on Power PC) Can't locate lib .pm - ?" - who is responsible for Power PC perl 5.8.5 port ?
> I think I've managed to fix some part of it ... > > [EMAIL PROTECTED]:/bin# perl -V > Summary of my perl5 (revision 5.0 version 8 subversion 2) > configuration: > Platform: > osname=linux, osvers=2.4.22-xfs, > archname=powerpc-linux-thread-multi > uname='linux vir 2.4.22-xfs #1 sun sep 14 20:26:05 est > 2003 ppc gnulinux . > but > > [EMAIL PROTECTED]:/bin# perl -e 'use lib;' > > produces no output it should *not* produce any output. Congratilations! You did it mostly by editing Config.pm? I beleive that adopting existing and working binaries currently easier than cross-compiling... Best regards, Vadim.
RE: new [PATCH] require Carp; vs. use Carp; in warnings.pm
> :Wasn't the point of Carp::Heavy to make this unnecessary? > If that's the > :case, fixing Carp would be a lot easier than changing "use Carp;" to > :"require Carp;" everywhere. > > "Necessary" or not is a sliding scale - I recently spent some > time trying > to reduce resource cost of a suite of CGI applications, and profiling > showed a lot of time lost loading useless modules such as > Carp, Exporter > etc. > > I was able to cut out some of the waste by hacking things at > installation > time (eg my installer replaces 'use strict' with the $^H bit-twiddling > it stands in for) but most of it is forced on me by standard modules. If speaking about this, want to add some my optimization notes. I perform editing of local copy of Dynaloader.pm of installed perl quite often. Dynaloader.pm contains a bunch of $^O checks and many my $ext=".dll"; $filename = "blablalba$ext"; When I do factoring out all of these, I get much lighter and still perfectly working dynaloader. Dynaloader.pm should be OS-specific, it is generated out from Dynaloader_pm.PL, so it is designed to be such, but this is only implemented by 50%. Why should my Win32 installation always check whether I am on VMS, MacOS or Linux? (and vice versa) XS_Loader.pm is much better in respect to this BTW. I will be happy to propose proper patch improving situation (not only Dynaloader suffers), but will it be approved as a good idea by comunity? (afraid of dont-fix-it-aint-broken stuff) Best regards, Vadim.
RE: crosscompile perl-5.8.5 source on cygwin (Intel/Windows) for PowerPC/ Linux 2.6 ?
> > How should I approach crosscompile perl-5.8.5 source on > cygwin (Intel/Windows) for PowerPC/Linux 2.6 ? > > (Can not use configure, I guess ? ) > > Why not? If all the utilities are in place, and Linux runs > fine, just fetch > the source, unpack and go Perl do not fully support crosscompiling, AFAIK Mostly you will go to target's miniperl that could be used instead of full perl (at least it is how many crosscompiles work, only WinCE gets full perl on target, but that totally different, as there's no configure step there.) However miniperl is mostly enough. > # cd /tmp > # wget > ftp://download.xs4all.nl/pub/mirror/CPAN/src/5.0/perl-5.8.5.tar.bz2 > # bzip2 -d # cd perl-5.8.5 > # ./Configure -des > # make > # make test > # make install Are you sure this will enable cross-compile? Best regards, Vadim.
RE: crosscompile perl-5.8.5 source on cygwin (Intel/Windows) for PowerPC/ Linux 2.6 ?
> > > > How should I approach crosscompile perl-5.8.5 source on > > > cygwin (Intel/Windows) for PowerPC/Linux 2.6 ? > > > > (Can not use configure, I guess ? ) > > > > > > Why not? If all the utilities are in place, and Linux runs > > > fine, just fetch > > > the source, unpack and go > > > > Perl do not fully support crosscompiling, AFAIK > > > > Mostly you will go to target's miniperl that could be used > instead of full > > perl (at least it is how many crosscompiles work, only > WinCE gets full perl > > on target, but that totally different, as there's no > configure step there.) > > > > However miniperl is mostly enough. > > > > > # cd /tmp > > > # wget > > > > ftp://download.xs4all.nl/pub/mirror/CPAN/src/5.0/perl-5.8.5.tar.bz2 > > > # bzip2 -d > > # cd perl-5.8.5 > > > # ./Configure -des > > > # make > > > # make test > > > # make install > > > > Are you sure this will enable cross-compile? > > Why would you need to cross-compile? > Once Linux is up and running, you've got it all there, haven't you? I gave exactly same advice yesterday to Alexander, in private mail. Looks like he has cross-compiler and do not has native compiler for some reasons. > > Or do you have to go back to cygwin to build stuff and start > Linux from there? cygwin runs on x86, target is PPC (power pc), so those are different computers. My satellite receiver is PPC processor that runs linux, so we have similar architectures, but I do quite little programming on it (although my receiver runs Perl correctly and I tend to calculate 2**1000 using bigint there :):):) ) > In that case I'd suggest building the devel environment > (bison, sed, awk, flex, > binutils, gcc, make) from cygwin to be present on your linux > environment and > continue in linux > > Cross compilation from Cygwin to linux does not sound like a > sane idea to me. indeed, using same cross-compilation chain compiled on Linux looks like better idea, and [EMAIL PROTECTED] is a very busy and helpful list for such reasons. > BTW does your Dynaloader work have cross-compiling in mind, > or does compiling > on cygwin/windows inhibit Dynaloader on the cross-target (linux) Dynaloader executes on TARGET and it is simple and should not know about cross-compilation. Dynaloader that used on HOST during cross-compiltion for WinCE also do not need knowing anything about that. So, no, Dynaloader work do not have any cross-compiling in mind Config.pm (and mostly Config.pm creation step) bothers about cross-compilation for WinCE. Best regards, Vadim.
RE: crosscompile perl-5.8.5 source on cygwin (Intel/Windows) for PowerPC/ Linux 2.6 ?
> > BTW does your Dynaloader work have cross-compiling in mind,
> > or does compiling
> > on cygwin/windows inhibit Dynaloader on the cross-target (linux)
>
> Dynaloader executes on TARGET and it is simple and should not
> know about
> cross-compilation.
> Dynaloader that used on HOST during cross-compiltion for
> WinCE also do not
> need knowing anything about that.
Okay, I thought a little and realized that Dynaloader_pm.PL could be invoked
with fake $^O so that it will generate Dynaloader.pm for target platform.
Here is a script to do that (I tested it yesterday) :
for my $O (qw(MacOS MSWin32 darwin os2 VMS cygwin linux sunos)) {
system("../../perl", '-we', "\$^O='$O';do './DynaLoader_pm.PL'");
`mv DynaLoader.pm DynaLoader-$O.pm`;
}
So Dynaloader_pm.PL could be used to create Dynaloader.pm for different $^O.
RE: [PATCH-for-23341] dynaloader improvements and cleanup
> > Please disregard my previous dynaloader patch and instead
> use current
> > one, it should be better WRT $ENV{PERL_BUILD_EXPAND_CONFIG_VARS}.
>
> Thanks, applied as #23348 to bleadperl.
> (Hmm, looking at those templates and substitutions, I was
> thinking about
> making TT a part of perl's build system... :)
Actually expand_os_specific makes things a bit more complicated from one
side, but it reduced several "print OUT ." into onle larger statement,
so made things a bit simplier.
Actually, as long as same thing should be performed for XS_loader and may be
some other files (lib_pm.pl), it could be reasonable to move subroutine
'expand_os_specific' somewhere (may be to lib/Devel/* directory)?
>
> > VK>> Additionally, I dare to ask community to allow me to
> remove AUTOLOAD
> > VK>> mechanic for Dynaloader, because IMHO it makes things
> a bit heavier
> > VK>> and a bit more complex without good gain.
> >
> > if no-one will argue against this, I will send a patch for this.
>
> Actually, I'd rather have PERL_BUILD_EXPAND_CONFIG_VARS and
> PERL_BUILD_EXPAND_ENV_VARS fixed that removed.
Ok, my patch improves situation a bit with PERL_BUILD_EXPAND_CONFIG_VARS
May in case it will remain in source tree, it should be documented as
well...
I found it only in 3 files:
Changes5.8
Dynaloader_pm.PL
lib_pm.PL
... and never documented.
Probably it is used to distinguish perl-lib search behaviour between ancient
(even before 5.004_02?) and modern perls ?
RE: perl ./configure failure (while attempting to configure for crosscomp ile build)
> I have attempted to cross-compile perl-5.8.5 on cygwin for linux/ppc > using my existant and test proven as working OK > powerpc-linux-gcc-3.3.2 > cross compiler ...it fails in compiling test program - I feel > that default libraries and includes, which ./configure used > are involved in that failure - what libraries and includes I > should input/use ? > > Thanks, > Alex > > $ pwd > /cygdrive/d/Profiles/apovolot/perl/perl-5.8.5 > > $ uname -a > CYGWIN_NT-5.1 USPITLAD104868 1.5.10(0.116/4/2) 2004-05-25 > 22:07 i686 unknown unknown Cygwin > > $ CC=powerpc-linux-gcc-3.3.2 LD=powerpc-linux-ld > AS=powerpc-linux-as ./configure my guess is that when you're doing cross-compile you should specify --target= in similar way as you do for cross-compiling GCC, to make configure chance to understand that it is performing a crosscompile. Perl currently has almost no support for crosscompiling, though, and I think this is all fixeable. Still, GCC has much more supoprt of crosscompiling, so moving GCC to PPC first and then compiling on PPC has more chances to survive, even with low system resources.
RE: perl@11278 - LAST CALL FOR 5.7.2
> >> http:[EMAIL PROTECTED]
> >
> > Am I the only person that started to have new failings (via
> core dump/GPF)
> > in the latest snapshot?
> >
> > Failed Test Stat Wstat Total Fail Failed List of Failed
> >
> --
> --
> > ---
> > op/pat.t 5 1280 6720 0.00% ??
> > op/regexp.t 29 7424 791 392 49.56% 400-791
> > op/regexp_noamp.t5 1280 791 392 49.56% 400-791
> > (3 subtests UNEXPECTEDLY SUCCEEDED), 41 tests and 173
> subtests skipped.
> > Failed 3/427 test scripts, 99.30% okay. 784/23580 subtests
> failed, 96.68%
> > okay.
> > dmake.exe: Error code 6, while making 'test'
> >
> > Am I the only person that has ext/ByteLoader not compilable
> without small
> > fix in ext/ByteLoader/bytecode.h:
> > (!following is NOT a PATCH, following is just to point place!)
> >
> > --- perl@11278-orig\ext\ByteLoader\bytecode.h Mon Jul
> 09 07:09:52 2001
> > +++ bytecode.h Wed Jul 11 21:30:42 2001
> > @@ -132,8 +132,10 @@
> > hv_store((HV*)sv, bstate->bs_pv.xpv_pv, bstate->bs_pv.xpv_cur, arg,
> > 0)
> > #define BSET_pv_free(pv) Safefree(pv.xpv_pv)
> > #define BSET_pregcomp(o, arg) \
> > - (PM_SETRE(((PMOP*)o), arg ? \
> > - CALLREGCOMP(aTHX_ arg, arg + bstate->bs_pv.xpv_cur,
> > ((PMOP*)o)) : 0))
> > + STMT_START {\
> > +pvcontents a = (arg ? CALLREGCOMP(aTHX_ arg, arg +
> > bstate->bs_pv.xpv_cur, ((PMOP*)o)) : 0);\
> > +PM_SETRE((PMOP*)o, a); \
> > + } STMT_END
>
>
> > #define BSET_newsv(sv, arg)\
> > STMT_START {\
> > sv = (arg == SVt_PVAV ? (SV*)newAV() : \
>
> It would seem the patch for moving the REGEX structure didn't
> work to well
> on Borland! Seems like the PM_SETRE macro is making something
> very unhappy.
>
> the macro is basicly
>
> (sv_setiv(PL_regex_pad[(o)->op_pmoffset], (IV)r))
>
> Could you try to compile without USEITHREADS and see what happens?
without USEITHREADS all tests okay. and I there were no syntax error that I tried to
fix eariler.
Additionally, I discovered that when I tried to build without perlio layer, there were
syntax errors (miniperl successfully built though), I'll look into this later.
Also I've discovered that lib/locale.t tests pass differently on my NT4 at work versus
Win2000 at home; I'll look into this later also, but I already know a couple of
reproducible bugs on Borland locale functions, so these failings are completely
different story.
Best wishes,
&Vadim;
