Building perl by yourself
Obtaining precompiled binaries
Known problems and their solutions
Future development directions
that wiki become read-only due to forced requirement on SF site.
this problem will not be fixed until people with enough enthusiasm will provide their help on fixing this
Starting from 5.9.4 version, in the Perl source tree 'wince' directory was merged with win32, so it is no more separate directory.
Build process is not changed, however.
Perl has support WinCE starting from 5.6.0 version, it was provided by Rainer Keuchel, along with other excellent software ported to WinCE platform available at his site.
Starting from perl version 5.8.0 build for WinCE has following additional features that were missing earlier:
Check that you have following:
compile.batfile to reflect your system configuration:
compile.bat. All should be compiled - miniperl for Win32, and entire perl for WinCE.
If nothing unusual happens, perl core and core libraries will be built. "
dist" will prepare a distribution for copying. If your mileage varies
so that you did not get your binaries that you deserve (yes, if you stepped
this way such long, you certainly deserve your binaries), then write to email@example.com
mailing list and share your experience.
compile.bat file is simple: it is a wrapper for wince/makefile.ce.
It prepares environment variables and then calls "nmake -f Makefile.ce"
with any extra arguments added to command line, and this provides a way to specify
make targets, specify platform name and so on.
Idea of cross-compiling process is also simple: during a cross-compiling process a special module "Cross.pm" is created, and a special "Config.pm" file hidden somewhere deep, and this Config file reflects parameters of your WinCE device. When module "Cross" is invoked then that special Config.pm comes into play.
If you want to try threaded build, then you should provide arguments "USE_ITHREADS=define" "USE_IMP_SYS=define" "USE_MULTI=define" to compile.bat file, all at once or some of them at your wish. Another way is to edit Makefile.ce appropriately. Be prepared to waste much more memory than usual in this case, just because there exists some black hole that is not noticed yet. More details will be published once they wil be available.
Building external perl extensions is not supported.
There are several reasons why it is not supported, most important reason is because nowadays
MakeMaker::Extutils is a huge collection of
XXX_DIR_YYY variables, because Perl supports
not only large number or platforms but yet large number of types of installations
thus resulting in gazillion number of totals.
It was decided to add just such minimum as possible at all.
However, building of external modules is possible, using a couple of simlpe tricks.
I'll provide details here when I'll gather more information. Until that please see how this is done for CPAN modules Tcl-0.72.tar.gz and TclTk-0.72.tar.gz -- both they contain ceMakefile.pl containing some information on question.
There was made very first attempt to build entire 5.8.1-pre for WinCE devices, it is available from download page for this project: http://sourceforge.net/project/showfiles.php?group_id=76681
'perlce-build-area' package contains so-called build area, which means entire files set after building process, including *.obj files and *.lib (those could be used for building extensions). This file is extremely large and usually is not needed for ordinary use.
If you experience some difficulties using pre-built binaries, please let me know
(currently installation isn't perfect. sorry for that)
In case you do not have yet celib.dll install it: many ports from Rainer Keuchel
use it, PerlCE also uses it. Download it from Rainer Keuchel's site or from
sourceforge site http://prdownloads.sourceforge.net/perlce/celib-3.11-dll-src.tar.gz
You do not need all files from inside that archive: just copy yours celib.dll into your \Windows directory. (other files are required if you're building binaries by yourself)
- unzip files, copy them preferably to storage card (to not occupy main memory
- edit Config.pm to reflect your installation path (globally replace string \storage card\perl58m into yours or do nothing if you unzipped perl into \storage card\perl58m)
- perl-at-19923 has misplaced files in ./lib/IO/* directory. Fixed in next release, please place files by yourself until that
- simply copy any desired pure-perl modules into ./lib and/or delete modules that you decided not to use to save memory
- update Dynaloader.pm with a file available separately for download. This file has logic for different OSes stripped (BTW why should my Win32 installation compare $^O with, say, 'VMS' every time?), much smaller in size and contains few WinCE-specific logic.
- help files are not provided. Instead you can just copy *.html files from usual perl distribution, and invoke it from Explorer.
Easiest way to deal with registry values is to use PerlIDE from http://www.rainer-keuchel.de/wince/dirlist.html
However perl.exe could be executed even without registry values set up properly.
There is a known feature on WinCE devices (or misfeature, depending on how you look at this :) when WinCE refuses to load a DLL if DLL with same name is already loaded. Regardless whether or not you specified exact path to new instance of DLL, a handle to firstly loaded DLL with same name will be returned.
This leads to a problem when file Socket.dll from perl directory becomes ignored just because WinCE has socket.dll in \Windows directory and it is usually loaded.
Avioding such problem is simple: rename file perl/lib/auto/Socket.dll into
Socket_1.dll and do a simple hacking of Dynaloader.pm to try *.dll at first
and *_1.dll at second.
updated Dynaloader.pm is available for download under perl-582-1 section, and handles namely this logic: it tries to download *_1.dll file as a secont attempt to download extension DLL.
Perl runs relatively fast on WinCE devices, but it takes quite long time to
start its run.
Mostly this is because perl needs to load its own DLL file. Given average WinCE device it takes about 1 second to load 1 Mbyte DLL file before using it (as of my Cassiopeia E-125). This is atomic operation and could not be faster than that.
The workaround is simple.
Just look into previous section and it will become clear that once we'll load perl.dll into memory it will not be loaded second time. Just write a simpe perl script that uses often required DLLs, and you'll save about 1 second each time some perl script will run. Some often used DLLs could be "prepared" using call to DynaLoader::dl_load_file("path_to_dll"); . Please make sure your "boost" script do not exit, it must be in background (finish it with a reading operator "<STDIN>;") and invoking next perl script will save about 1 second per required 1 MByte DLL.
Threaded Perl is way experimental on WinCE and it appeared right before 5.8.1 is out. May be sometimes it will be more tested, now it works as "just to prove it works".
(no more problem as of 5.8.6+)
(no more problem as of 5.8.2+)
Yes, better explanations should be done with a person who knows English better than me. Please post corrections to said mailing list, or ask there about unclear places and together we'll improve explanations.
If you want most recent information please use firstname.lastname@example.org
Subscribe to that list by filling your address at URL http://lists.sourceforge.net/lists/listinfo/perlce-user
last updated: 16-nov-2006