1 |
NAME |
2 |
staticperl - perl, libc, 100 modules, all in one 500kb file |
3 |
|
4 |
SYNOPSIS |
5 |
staticperl help # print the embedded documentation |
6 |
staticperl fetch # fetch and unpack perl sources |
7 |
staticperl configure # fetch and then configure perl |
8 |
staticperl build # configure and then build perl |
9 |
staticperl install # build and then install perl |
10 |
staticperl clean # clean most intermediate files (restart at configure) |
11 |
staticperl distclean # delete everything installed by this script |
12 |
staticperl cpan # invoke CPAN shell |
13 |
staticperl instmod path... # install unpacked modules |
14 |
staticperl instcpan modulename... # install modules from CPAN |
15 |
staticperl mkbundle <bundle-args...> # see documentation |
16 |
staticperl mkperl <bundle-args...> # see documentation |
17 |
staticperl mkapp appname <bundle-args...> # see documentation |
18 |
|
19 |
Typical Examples: |
20 |
|
21 |
staticperl install # fetch, configure, build and install perl |
22 |
staticperl cpan # run interactive cpan shell |
23 |
staticperl mkperl -MConfig_heavy.pl # build a perl that supports -V |
24 |
staticperl mkperl -MAnyEvent::Impl::Perl -MAnyEvent::HTTPD -MURI -MURI::http |
25 |
# build a perl with the above modules linked in |
26 |
staticperl mkapp myapp --boot mainprog mymodules |
27 |
# build a binary "myapp" from mainprog and mymodules |
28 |
|
29 |
DESCRIPTION |
30 |
This script helps you to create single-file perl interpreters or |
31 |
applications, or embedding a perl interpreter in your applications. |
32 |
Single-file means that it is fully self-contained - no separate shared |
33 |
objects, no autoload fragments, no .pm or .pl files are needed. And when |
34 |
linking statically, you can create (or embed) a single file that |
35 |
contains perl interpreter, libc, all the modules you need, all the |
36 |
libraries you need and of course your actual program. |
37 |
|
38 |
With uClibc and upx on x86, you can create a single 500kb binary that |
39 |
contains perl and 100 modules such as POSIX, AnyEvent, EV, IO::AIO, Coro |
40 |
and so on. Or any other choice of modules. |
41 |
|
42 |
To see how this turns out, you can try out smallperl and bigperl, two |
43 |
pre-built static and compressed perl binaries with many and even more |
44 |
modules: just follow the links at <http://staticperl.schmorp.de/>. |
45 |
|
46 |
The created files do not need write access to the file system (like PAR |
47 |
does). In fact, since this script is in many ways similar to |
48 |
PAR::Packer, here are the differences: |
49 |
|
50 |
* The generated executables are much smaller than PAR created ones. |
51 |
|
52 |
Shared objects and the perl binary contain a lot of extra info, |
53 |
while the static nature of staticperl allows the linker to remove |
54 |
all functionality and meta-info not required by the final |
55 |
executable. Even extensions statically compiled into perl at build |
56 |
time will only be present in the final executable when needed. |
57 |
|
58 |
In addition, staticperl can strip perl sources much more effectively |
59 |
than PAR. |
60 |
|
61 |
* The generated executables start much faster. |
62 |
|
63 |
There is no need to unpack files, or even to parse Zip archives |
64 |
(which is slow and memory-consuming business). |
65 |
|
66 |
* The generated executables don't need a writable filesystem. |
67 |
|
68 |
staticperl loads all required files directly from memory. There is |
69 |
no need to unpack files into a temporary directory. |
70 |
|
71 |
* More control over included files, more burden. |
72 |
|
73 |
PAR tries to be maintenance and hassle-free - it tries to include |
74 |
more files than necessary to make sure everything works out of the |
75 |
box. It mostly succeeds at this, but he extra files (such as the |
76 |
unicode database) can take substantial amounts of memory and file |
77 |
size. |
78 |
|
79 |
With staticperl, the burden is mostly with the developer - only |
80 |
direct compile-time dependencies and AutoLoader are handled |
81 |
automatically. This means the modules to include often need to be |
82 |
tweaked manually. |
83 |
|
84 |
All this does not preclude more permissive modes to be implemented |
85 |
in the future, but right now, you have to resolve state hidden |
86 |
dependencies manually. |
87 |
|
88 |
* PAR works out of the box, staticperl does not. |
89 |
|
90 |
Maintaining your own custom perl build can be a pain in the ass, and |
91 |
while staticperl tries to make this easy, it still requires a custom |
92 |
perl build and possibly fiddling with some modules. PAR is likely to |
93 |
produce results faster. |
94 |
|
95 |
Ok, PAR never has worked for me out of the box, and for some people, |
96 |
staticperl does work out of the box, as they don't count "fiddling |
97 |
with module use lists" against it, but nevertheless, staticperl is |
98 |
certainly a bit more difficult to use. |
99 |
|
100 |
HOW DOES IT WORK? |
101 |
Simple: staticperl downloads, compile and installs a perl version of |
102 |
your choice in ~/.staticperl. You can add extra modules either by |
103 |
letting staticperl install them for you automatically, or by using CPAN |
104 |
and doing it interactively. This usually takes 5-10 minutes, depending |
105 |
on the speed of your computer and your internet connection. |
106 |
|
107 |
It is possible to do program development at this stage, too. |
108 |
|
109 |
Afterwards, you create a list of files and modules you want to include, |
110 |
and then either build a new perl binary (that acts just like a normal |
111 |
perl except everything is compiled in), or you create bundle files |
112 |
(basically C sources you can use to embed all files into your project). |
113 |
|
114 |
This step is very fast (a few seconds if PPI is not used for stripping, |
115 |
or the stripped files are in the cache), and can be tweaked and repeated |
116 |
as often as necessary. |
117 |
|
118 |
THE STATICPERL SCRIPT |
119 |
This module installs a script called staticperl into your perl binary |
120 |
directory. The script is fully self-contained, and can be used without |
121 |
perl (for example, in an uClibc chroot environment). In fact, it can be |
122 |
extracted from the "App::Staticperl" distribution tarball as |
123 |
bin/staticperl, without any installation. The newest (possibly alpha) |
124 |
version can also be downloaded from |
125 |
<http://staticperl.schmorp.de/staticperl>. |
126 |
|
127 |
staticperl interprets the first argument as a command to execute, |
128 |
optionally followed by any parameters. |
129 |
|
130 |
There are two command categories: the "phase 1" commands which deal with |
131 |
installing perl and perl modules, and the "phase 2" commands, which deal |
132 |
with creating binaries and bundle files. |
133 |
|
134 |
PHASE 1 COMMANDS: INSTALLING PERL |
135 |
The most important command is install, which does basically everything. |
136 |
The default is to download and install perl 5.12.3 and a few modules |
137 |
required by staticperl itself, but all this can (and should) be changed |
138 |
- see CONFIGURATION, below. |
139 |
|
140 |
The command |
141 |
|
142 |
staticperl install |
143 |
|
144 |
is normally all you need: It installs the perl interpreter in |
145 |
~/.staticperl/perl. It downloads, configures, builds and installs the |
146 |
perl interpreter if required. |
147 |
|
148 |
Most of the following staticperl subcommands simply run one or more |
149 |
steps of this sequence. |
150 |
|
151 |
If it fails, then most commonly because the compiler options I selected |
152 |
are not supported by your compiler - either edit the staticperl script |
153 |
yourself or create ~/.staticperl shell script where your set working |
154 |
"PERL_CCFLAGS" etc. variables. |
155 |
|
156 |
To force recompilation or reinstallation, you need to run staticperl |
157 |
distclean first. |
158 |
|
159 |
staticperl version |
160 |
Prints some info about the version of the staticperl script you are |
161 |
using. |
162 |
|
163 |
staticperl fetch |
164 |
Runs only the download and unpack phase, unless this has already |
165 |
happened. |
166 |
|
167 |
staticperl configure |
168 |
Configures the unpacked perl sources, potentially after downloading |
169 |
them first. |
170 |
|
171 |
staticperl build |
172 |
Builds the configured perl sources, potentially after automatically |
173 |
configuring them. |
174 |
|
175 |
staticperl install |
176 |
Wipes the perl installation directory (usually ~/.staticperl/perl) |
177 |
and installs the perl distribution, potentially after building it |
178 |
first. |
179 |
|
180 |
staticperl cpan [args...] |
181 |
Starts an interactive CPAN shell that you can use to install further |
182 |
modules. Installs the perl first if necessary, but apart from that, |
183 |
no magic is involved: you could just as well run it manually via |
184 |
~/.staticperl/perl/bin/cpan. |
185 |
|
186 |
Any additional arguments are simply passed to the cpan command. |
187 |
|
188 |
staticperl instcpan module... |
189 |
Tries to install all the modules given and their dependencies, using |
190 |
CPAN. |
191 |
|
192 |
Example: |
193 |
|
194 |
staticperl instcpan EV AnyEvent::HTTPD Coro |
195 |
|
196 |
staticperl instsrc directory... |
197 |
In the unlikely case that you have unpacked perl modules around and |
198 |
want to install from these instead of from CPAN, you can do this |
199 |
using this command by specifying all the directories with modules in |
200 |
them that you want to have built. |
201 |
|
202 |
staticperl clean |
203 |
Deletes the perl source directory (and potentially cleans up other |
204 |
intermediate files). This can be used to clean up files only needed |
205 |
for building perl, without removing the installed perl interpreter. |
206 |
|
207 |
At the moment, it doesn't delete downloaded tarballs. |
208 |
|
209 |
The exact semantics of this command will probably change. |
210 |
|
211 |
staticperl distclean |
212 |
This wipes your complete ~/.staticperl directory. Be careful with |
213 |
this, it nukes your perl download, perl sources, perl distribution |
214 |
and any installed modules. It is useful if you wish to start over |
215 |
"from scratch" or when you want to uninstall staticperl. |
216 |
|
217 |
PHASE 2 COMMANDS: BUILDING PERL BUNDLES |
218 |
Building (linking) a new perl binary is handled by a separate script. To |
219 |
make it easy to use staticperl from a chroot, the script is embedded |
220 |
into staticperl, which will write it out and call for you with any |
221 |
arguments you pass: |
222 |
|
223 |
staticperl mkbundle mkbundle-args... |
224 |
|
225 |
In the oh so unlikely case of something not working here, you can run |
226 |
the script manually as well (by default it is written to |
227 |
~/.staticperl/mkbundle). |
228 |
|
229 |
mkbundle is a more conventional command and expect the argument syntax |
230 |
commonly used on UNIX clones. For example, this command builds a new |
231 |
perl binary and includes Config.pm (for perl -V), AnyEvent::HTTPD, URI |
232 |
and a custom httpd script (from eg/httpd in this distribution): |
233 |
|
234 |
# first make sure we have perl and the required modules |
235 |
staticperl instcpan AnyEvent::HTTPD |
236 |
|
237 |
# now build the perl |
238 |
staticperl mkperl -MConfig_heavy.pl -MAnyEvent::Impl::Perl \ |
239 |
-MAnyEvent::HTTPD -MURI::http \ |
240 |
--add 'eg/httpd httpd.pm' |
241 |
|
242 |
# finally, invoke it |
243 |
./perl -Mhttpd |
244 |
|
245 |
As you can see, things are not quite as trivial: the Config module has a |
246 |
hidden dependency which is not even a perl module (Config_heavy.pl), |
247 |
AnyEvent needs at least one event loop backend that we have to specify |
248 |
manually (here AnyEvent::Impl::Perl), and the URI module (required by |
249 |
AnyEvent::HTTPD) implements various URI schemes as extra modules - since |
250 |
AnyEvent::HTTPD only needs "http" URIs, we only need to include that |
251 |
module. I found out about these dependencies by carefully watching any |
252 |
error messages about missing modules... |
253 |
|
254 |
Instead of building a new perl binary, you can also build a standalone |
255 |
application: |
256 |
|
257 |
# build the app |
258 |
staticperl mkapp app --boot eg/httpd \ |
259 |
-MAnyEvent::Impl::Perl -MAnyEvent::HTTPD -MURI::http |
260 |
|
261 |
# run it |
262 |
./app |
263 |
|
264 |
Here are the three phase 2 commands: |
265 |
|
266 |
staticperl mkbundle args... |
267 |
The "default" bundle command - it interprets the given bundle |
268 |
options and writes out bundle.h, bundle.c, bundle.ccopts and |
269 |
bundle.ldopts files, useful for embedding. |
270 |
|
271 |
staticperl mkperl args... |
272 |
Creates a bundle just like staticperl mkbundle (in fact, it's the |
273 |
same as invoking staticperl mkbundle --perl args...), but then |
274 |
compiles and links a new perl interpreter that embeds the created |
275 |
bundle, then deletes all intermediate files. |
276 |
|
277 |
staticperl mkapp filename args... |
278 |
Does the same as staticperl mkbundle (in fact, it's the same as |
279 |
invoking staticperl mkbundle --app filename args...), but then |
280 |
compiles and links a new standalone application that simply |
281 |
initialises the perl interpreter. |
282 |
|
283 |
The difference to staticperl mkperl is that the standalone |
284 |
application does not act like a perl interpreter would - in fact, by |
285 |
default it would just do nothing and exit immediately, so you should |
286 |
specify some code to be executed via the --boot option. |
287 |
|
288 |
OPTION PROCESSING |
289 |
All options can be given as arguments on the command line (typically |
290 |
using long (e.g. "--verbose") or short option (e.g. "-v") style). Since |
291 |
specifying a lot of options can make the command line very long and |
292 |
unwieldy, you can put all long options into a "bundle specification |
293 |
file" (one option per line, with or without "--" prefix) and specify |
294 |
this bundle file instead. |
295 |
|
296 |
For example, the command given earlier to link a new perl could also |
297 |
look like this: |
298 |
|
299 |
staticperl mkperl httpd.bundle |
300 |
|
301 |
With all options stored in the httpd.bundle file (one option per line, |
302 |
everything after the option is an argument): |
303 |
|
304 |
use "Config_heavy.pl" |
305 |
use AnyEvent::Impl::Perl |
306 |
use AnyEvent::HTTPD |
307 |
use URI::http |
308 |
add eg/httpd httpd.pm |
309 |
|
310 |
All options that specify modules or files to be added are processed in |
311 |
the order given on the command line. |
312 |
|
313 |
BUNDLE CREATION WORKFLOW / STATICPELR MKBUNDLE OPTIONS |
314 |
staticperl mkbundle works by first assembling a list of candidate files |
315 |
and modules to include, then filtering them by include/exclude patterns. |
316 |
The remaining modules (together with their direct dependencies, such as |
317 |
link libraries and AutoLoader files) are then converted into bundle |
318 |
files suitable for embedding. staticperl mkbundle can then optionally |
319 |
build a new perl interpreter or a standalone application. |
320 |
|
321 |
Step 0: Generic argument processing. |
322 |
The following options influence staticperl mkbundle itself. |
323 |
|
324 |
"--verbose" | "-v" |
325 |
Increases the verbosity level by one (the default is 1). |
326 |
|
327 |
"--quiet" | "-q" |
328 |
Decreases the verbosity level by one. |
329 |
|
330 |
any other argument |
331 |
Any other argument is interpreted as a bundle specification |
332 |
file, which supports all options (without extra quoting), one |
333 |
option per line, in the format "option" or "option argument". |
334 |
They will effectively be expanded and processed as if they were |
335 |
directly written on the command line, in place of the file name. |
336 |
|
337 |
Step 1: gather candidate files and modules |
338 |
In this step, modules, perl libraries (.pl files) and other files |
339 |
are selected for inclusion in the bundle. The relevant options are |
340 |
executed in order (this makes a difference mostly for "--eval", |
341 |
which can rely on earlier "--use" options to have been executed). |
342 |
|
343 |
"--use" module | "-M"module |
344 |
Include the named module or perl library and trace direct |
345 |
dependencies. This is done by loading the module in a subprocess |
346 |
and tracing which other modules and files it actually loads. |
347 |
|
348 |
Example: include AnyEvent and AnyEvent::Impl::Perl. |
349 |
|
350 |
staticperl mkbundle --use AnyEvent --use AnyEvent::Impl::Perl |
351 |
|
352 |
Sometimes you want to load old-style "perl libraries" (.pl |
353 |
files), or maybe other weirdly named files. To support this, the |
354 |
"--use" option actually tries to do what you mean, depending on |
355 |
the string you specify: |
356 |
|
357 |
a possibly valid module name, e.g. common::sense, Carp, |
358 |
Coro::Mysql. |
359 |
If the string contains no quotes, no / and no ., then |
360 |
"--use" assumes that it is a normal module name. It will |
361 |
create a new package and evaluate a "use module" in it, i.e. |
362 |
it will load the package and do a default import. |
363 |
|
364 |
The import step is done because many modules trigger more |
365 |
dependencies when something is imported than without. |
366 |
|
367 |
anything that contains / or . characters, e.g. utf8_heavy.pl, |
368 |
Module/private/data.pl. |
369 |
The string will be quoted and passed to require, as if you |
370 |
used "require $module". Nothing will be imported. |
371 |
|
372 |
"path" or 'path', e.g. "utf8_heavy.pl". |
373 |
If you enclose the name into single or double quotes, then |
374 |
the quotes will be removed and the resulting string will be |
375 |
passed to require. This syntax is form compatibility with |
376 |
older versions of staticperl and should not be used anymore. |
377 |
|
378 |
Example: "use" AnyEvent::Socket, once using "use" (importing the |
379 |
symbols), and once via "require", not importing any symbols. The |
380 |
first form is preferred as many modules load some extra |
381 |
dependencies when asked to export symbols. |
382 |
|
383 |
staticperl mkbundle -MAnyEvent::Socket # use + import |
384 |
staticperl mkbundle -MAnyEvent/Socket.pm # require only |
385 |
|
386 |
Example: include the required files for perl -V to work in all |
387 |
its glory (Config.pm is included automatically by the dependency |
388 |
tracker). |
389 |
|
390 |
# shell command |
391 |
staticperl mkbundle -MConfig_heavy.pl |
392 |
|
393 |
# bundle specification file |
394 |
use Config_heavy.pl |
395 |
|
396 |
The "-M"module syntax is included as a convenience that might be |
397 |
easier to remember than "--use" - it's the same switch as perl |
398 |
itself uses to load modules. Or maybe it confuses people. Time |
399 |
will tell. Or maybe not. Sigh. |
400 |
|
401 |
"--eval" "perl code" | "-e" "perl code" |
402 |
Sometimes it is easier (or necessary) to specify dependencies |
403 |
using perl code, or maybe one of the modules you use need a |
404 |
special use statement. In that case, you can use "--eval" to |
405 |
execute some perl snippet or set some variables or whatever you |
406 |
need. All files "require"'d or "use"'d while executing the |
407 |
snippet are included in the final bundle. |
408 |
|
409 |
Keep in mind that mkbundle will not import any symbols from the |
410 |
modules named by the "--use" option, so do not expect the |
411 |
symbols from modules you "--use"'d earlier on the command line |
412 |
to be available. |
413 |
|
414 |
Example: force AnyEvent to detect a backend and therefore |
415 |
include it in the final bundle. |
416 |
|
417 |
staticperl mkbundle --eval 'use AnyEvent; AnyEvent::detect' |
418 |
|
419 |
# or like this |
420 |
staticperl mkbundle -MAnyEvent --eval 'AnyEvent::detect' |
421 |
|
422 |
Example: use a separate "bootstrap" script that "use"'s lots of |
423 |
modules and also include this in the final bundle, to be |
424 |
executed automatically when the interpreter is initialised. |
425 |
|
426 |
staticperl mkbundle --eval 'do "bootstrap"' --boot bootstrap |
427 |
|
428 |
"--boot" filename |
429 |
Include the given file in the bundle and arrange for it to be |
430 |
executed (using "require") before the main program when the new |
431 |
perl is initialised. This can be used to modify @INC or do |
432 |
similar modifications before the perl interpreter executes |
433 |
scripts given on the command line (or via "-e"). This works even |
434 |
in an embedded interpreter - the file will be executed during |
435 |
interpreter initialisation in that case. |
436 |
|
437 |
"--incglob" pattern |
438 |
This goes through all standard library directories and tries to |
439 |
match any .pm and .pl files against the extended glob pattern |
440 |
(see below). If a file matches, it is added. The pattern is |
441 |
matched against the full path of the file (sans the library |
442 |
directory prefix), e.g. Sys/Syslog.pm. |
443 |
|
444 |
This is very useful to include "everything": |
445 |
|
446 |
--incglob '*' |
447 |
|
448 |
It is also useful for including perl libraries, or trees of |
449 |
those, such as the unicode database files needed by some perl |
450 |
built-ins, the regex engine and other modules. |
451 |
|
452 |
--incglob '/unicore/**.pl' |
453 |
|
454 |
"--add" file | "--add" "file alias" |
455 |
Adds the given (perl) file into the bundle (and optionally call |
456 |
it "alias"). The file is either an absolute path or a path |
457 |
relative to the current directory. If an alias is specified, |
458 |
then this is the name it will use for @INC searches, otherwise |
459 |
the path file will be used as the internal name. |
460 |
|
461 |
This switch is used to include extra files into the bundle. |
462 |
|
463 |
Example: embed the file httpd in the current directory as |
464 |
httpd.pm when creating the bundle. |
465 |
|
466 |
staticperl mkperl --add "httpd httpd.pm" |
467 |
|
468 |
# can be accessed via "use httpd" |
469 |
|
470 |
Example: add a file initcode from the current directory. |
471 |
|
472 |
staticperl mkperl --add 'initcode &initcode' |
473 |
|
474 |
# can be accessed via "do '&initcode'" |
475 |
|
476 |
Example: add local files as extra modules in the bundle. |
477 |
|
478 |
# specification file |
479 |
add file1 myfiles/file1.pm |
480 |
add file2 myfiles/file2.pm |
481 |
add file3 myfiles/file3.pl |
482 |
|
483 |
# then later, in perl, use |
484 |
use myfiles::file1; |
485 |
require myfiles::file2; |
486 |
my $res = do "myfiles/file3.pl"; |
487 |
|
488 |
"--binadd" file | "--add" "file alias" |
489 |
Just like "--add", except that it treats the file as binary and |
490 |
adds it without any postprocessing (perl files might get |
491 |
stripped to reduce their size). |
492 |
|
493 |
If you specify an alias you should probably add a "&" prefix to |
494 |
avoid clashing with embedded perl files (whose paths never start |
495 |
with "&"), and/or use a special directory prefix, such as |
496 |
"&res/name". |
497 |
|
498 |
You can later get a copy of these files by calling |
499 |
"staticperl::find "alias"". |
500 |
|
501 |
An alternative way to embed binary files is to convert them to |
502 |
perl and use "do" to get the contents - this method is a bit |
503 |
cumbersome, but works both inside and outside of a staticperl |
504 |
bundle: |
505 |
|
506 |
# a "binary" file, call it "bindata.pl" |
507 |
<<'SOME_MARKER' |
508 |
binary data NOT containing SOME_MARKER |
509 |
SOME_MARKER |
510 |
|
511 |
# load the binary |
512 |
chomp (my $data = do "bindata.pl"); |
513 |
|
514 |
Step 2: filter all files using "--include" and "--exclude" options. |
515 |
After all candidate files and modules are added, they are *filtered* |
516 |
by a combination of "--include" and "--exclude" patterns (there is |
517 |
an implicit "--include *" at the end, so if no filters are |
518 |
specified, all files are included). |
519 |
|
520 |
All that this step does is potentially reduce the number of files |
521 |
that are to be included - no new files are added during this step. |
522 |
|
523 |
"--include" pattern | "-i" pattern | "--exclude" pattern | "-x" |
524 |
pattern |
525 |
These specify an include or exclude pattern to be applied to the |
526 |
candidate file list. An include makes sure that the given files |
527 |
will be part of the resulting file set, an exclude will exclude |
528 |
remaining files. The patterns are "extended glob patterns" (see |
529 |
below). |
530 |
|
531 |
The patterns are applied "in order" - files included via earlier |
532 |
"--include" specifications cannot be removed by any following |
533 |
"--exclude", and likewise, and file excluded by an earlier |
534 |
"--exclude" cannot be added by any following "--include". |
535 |
|
536 |
For example, to include everything except "Devel" modules, but |
537 |
still include Devel::PPPort, you could use this: |
538 |
|
539 |
--incglob '*' -i '/Devel/PPPort.pm' -x '/Devel/**' |
540 |
|
541 |
Step 3: add any extra or "hidden" dependencies. |
542 |
staticperl currently knows about three extra types of depdendencies |
543 |
that are added automatically. Only one (.packlist files) is |
544 |
currently optional and can be influenced, the others are always |
545 |
included: |
546 |
|
547 |
"--usepacklists" |
548 |
Read .packlist files for each distribution that happens to match |
549 |
a module name you specified. Sounds weird, and it is, so expect |
550 |
semantics to change somehow in the future. |
551 |
|
552 |
The idea is that most CPAN distributions have a .pm file that |
553 |
matches the name of the distribution (which is rather reasonable |
554 |
after all). |
555 |
|
556 |
If this switch is enabled, then if any of the .pm files that |
557 |
have been selected match an install distribution, then all .pm, |
558 |
.pl, .al and .ix files installed by this distribution are also |
559 |
included. |
560 |
|
561 |
For example, using this switch, when the URI module is |
562 |
specified, then all URI submodules that have been installed via |
563 |
the CPAN distribution are included as well, so you don't have to |
564 |
manually specify them. |
565 |
|
566 |
AutoLoader splitfiles |
567 |
Some modules use AutoLoader - less commonly (hopefully) used |
568 |
functions are split into separate .al files, and an index (.ix) |
569 |
file contains the prototypes. |
570 |
|
571 |
Both .ix and .al files will be detected automatically and added |
572 |
to the bundle. |
573 |
|
574 |
link libraries (.a files) |
575 |
Modules using XS (or any other non-perl language extension |
576 |
compiled at installation time) will have a static archive |
577 |
(typically .a). These will automatically be added to the linker |
578 |
options in bundle.ldopts. |
579 |
|
580 |
Should staticperl find a dynamic link library (typically .so) it |
581 |
will warn about it - obviously this shouldn't happen unless you |
582 |
use staticperl on the wrong perl, or one (probably wrongly) |
583 |
configured to use dynamic loading. |
584 |
|
585 |
extra libraries (extralibs.ld) |
586 |
Some modules need linking against external libraries - these are |
587 |
found in extralibs.ld and added to bundle.ldopts. |
588 |
|
589 |
Step 4: write bundle files and optionally link a program |
590 |
At this point, the select files will be read, processed (stripped) |
591 |
and finally the bundle files get written to disk, and staticperl |
592 |
mkbundle is normally finished. Optionally, it can go a step further |
593 |
and either link a new perl binary with all selected modules and |
594 |
files inside, or build a standalone application. |
595 |
|
596 |
Both the contents of the bundle files and any extra linking is |
597 |
controlled by these options: |
598 |
|
599 |
"--strip" "none"|"pod"|"ppi" |
600 |
Specify the stripping method applied to reduce the file of the |
601 |
perl sources included. |
602 |
|
603 |
The default is "pod", which uses the Pod::Strip module to remove |
604 |
all pod documentation, which is very fast and reduces file size |
605 |
a lot. |
606 |
|
607 |
The "ppi" method uses PPI to parse and condense the perl |
608 |
sources. This saves a lot more than just Pod::Strip, and is |
609 |
generally safer, but is also a lot slower (some files take |
610 |
almost a minute to strip - staticperl maintains a cache of |
611 |
stripped files to speed up subsequent runs for this reason). |
612 |
Note that this method doesn't optimise for raw file size, but |
613 |
for best compression (that means that the uncompressed file size |
614 |
is a bit larger, but the files compress better, e.g. with upx). |
615 |
|
616 |
Last not least, if you need accurate line numbers in error |
617 |
messages, or in the unlikely case where "pod" is too slow, or |
618 |
some module gets mistreated, you can specify "none" to not |
619 |
mangle included perl sources in any way. |
620 |
|
621 |
"--perl" |
622 |
After writing out the bundle files, try to link a new perl |
623 |
interpreter. It will be called perl and will be left in the |
624 |
current working directory. The bundle files will be removed. |
625 |
|
626 |
This switch is automatically used when staticperl is invoked |
627 |
with the "mkperl" command instead of "mkbundle". |
628 |
|
629 |
Example: build a new ./perl binary with only common::sense |
630 |
inside - it will be even smaller than the standard perl |
631 |
interpreter as none of the modules of the base distribution |
632 |
(such as Fcntl) will be included. |
633 |
|
634 |
staticperl mkperl -Mcommon::sense |
635 |
|
636 |
"--app" name |
637 |
After writing out the bundle files, try to link a new standalone |
638 |
program. It will be called "name", and the bundle files get |
639 |
removed after linking it. |
640 |
|
641 |
This switch is automatically used when staticperl is invoked |
642 |
with the "mkapp" command instead of "mkbundle". |
643 |
|
644 |
The difference to the (mutually exclusive) "--perl" option is |
645 |
that the binary created by this option will not try to act as a |
646 |
perl interpreter - instead it will simply initialise the perl |
647 |
interpreter, clean it up and exit. |
648 |
|
649 |
This means that, by default, it will do nothing but burn a few |
650 |
CPU cycles - for it to do something useful you *must* add some |
651 |
boot code, e.g. with the "--boot" option. |
652 |
|
653 |
Example: create a standalone perl binary called ./myexe that |
654 |
will execute appfile when it is started. |
655 |
|
656 |
staticperl mkbundle --app myexe --boot appfile |
657 |
|
658 |
"--ignore-env" |
659 |
Generates extra code to unset some environment variables before |
660 |
initialising/running perl. Perl supports a lot of environment |
661 |
variables that might alter execution in ways that might be |
662 |
undesirablre for standalone applications, and this option |
663 |
removes those known to cause trouble. |
664 |
|
665 |
Specifically, these are removed: |
666 |
|
667 |
"PERL_HASH_SEED_DEBUG" and "PERL_DEBUG_MSTATS" can cause |
668 |
underaible output, "PERL5OPT", "PERL_DESTRUCT_LEVEL", |
669 |
"PERL_HASH_SEED" and "PERL_SIGNALS" can alter execution |
670 |
significantly, and "PERL_UNICODE", "PERLIO_DEBUG" and "PERLIO" |
671 |
can affect input and output. |
672 |
|
673 |
The variables "PERL_LIB" and "PERL5_LIB" are always ignored |
674 |
because the startup code used by staticperl overrides @INC in |
675 |
all cases. |
676 |
|
677 |
This option will not make your program more secure (unless you |
678 |
are running with elevated privileges), but it will reduce the |
679 |
surprise effect when a user has these environment variables set |
680 |
and doesn't expect your standalone program to act like a perl |
681 |
interpreter. |
682 |
|
683 |
"--static" |
684 |
Add "-static" to bundle.ldopts, which means a fully static (if |
685 |
supported by the OS) executable will be created. This is not |
686 |
immensely useful when just creating the bundle files, but is |
687 |
most useful when linking a binary with the "--perl" or "--app" |
688 |
options. |
689 |
|
690 |
The default is to link the new binary dynamically (that means |
691 |
all perl modules are linked statically, but all external |
692 |
libraries are still referenced dynamically). |
693 |
|
694 |
Keep in mind that Solaris doesn't support static linking at all, |
695 |
and systems based on GNU libc don't really support it in a very |
696 |
usable fashion either. Try uClibc if you want to create fully |
697 |
statically linked executables, or try the "--staticlib" option |
698 |
to link only some libraries statically. |
699 |
|
700 |
"--staticlib" libname |
701 |
When not linking fully statically, this option allows you to |
702 |
link specific libraries statically. What it does is simply |
703 |
replace all occurrences of "-llibname" with the GCC-specific |
704 |
"-Wl,-Bstatic -llibname -Wl,-Bdynamic" option. |
705 |
|
706 |
This will have no effect unless the library is actually linked |
707 |
against, specifically, "--staticlib" will not link against the |
708 |
named library unless it would be linked against anyway. |
709 |
|
710 |
Example: link libcrypt statically into the final binary. |
711 |
|
712 |
staticperl mkperl -MIO::AIO --staticlib crypt |
713 |
|
714 |
# ldopts might now contain: |
715 |
# -lm -Wl,-Bstatic -lcrypt -Wl,-Bdynamic -lpthread |
716 |
|
717 |
EXTENDED GLOB PATTERNS |
718 |
Some options of staticperl mkbundle expect an *extended glob pattern*. |
719 |
This is neither a normal shell glob nor a regex, but something in |
720 |
between. The idea has been copied from rsync, and there are the current |
721 |
matching rules: |
722 |
|
723 |
Patterns starting with / will be a anchored at the root of the library |
724 |
tree. |
725 |
That is, /unicore will match the unicore directory in @INC, but |
726 |
nothing inside, and neither any other file or directory called |
727 |
unicore anywhere else in the hierarchy. |
728 |
|
729 |
Patterns not starting with / will be anchored at the end of the path. |
730 |
That is, idna.pl will match any file called idna.pl anywhere in the |
731 |
hierarchy, but not any directories of the same name. |
732 |
|
733 |
A * matches anything within a single path component. |
734 |
That is, /unicore/*.pl would match all .pl files directly inside |
735 |
"/unicore", not any deeper level .pl files. Or in other words, * |
736 |
will not match slashes. |
737 |
|
738 |
A ** matches anything. |
739 |
That is, /unicore/**.pl would match all .pl files under /unicore, no |
740 |
matter how deeply nested they are inside subdirectories. |
741 |
|
742 |
A ? matches a single character within a component. |
743 |
That is, /Encode/??.pm matches /Encode/JP.pm, but not the |
744 |
hypothetical /Encode/J/.pm, as ? does not match /. |
745 |
|
746 |
STATICPERL CONFIGURATION AND HOOKS |
747 |
During (each) startup, staticperl tries to source some shell files to |
748 |
allow you to fine-tune/override configuration settings. |
749 |
|
750 |
In them you can override shell variables, or define shell functions |
751 |
("hooks") to be called at specific phases during installation. For |
752 |
example, you could define a "postinstall" hook to install additional |
753 |
modules from CPAN each time you start from scratch. |
754 |
|
755 |
If the env variable $STATICPERLRC is set, then staticperl will try to |
756 |
source the file named with it only. Otherwise, it tries the following |
757 |
shell files in order: |
758 |
|
759 |
/etc/staticperlrc |
760 |
~/.staticperlrc |
761 |
$STATICPERL/rc |
762 |
|
763 |
Note that the last file is erased during staticperl distclean, so |
764 |
generally should not be used. |
765 |
|
766 |
CONFIGURATION VARIABLES |
767 |
Variables you *should* override |
768 |
"EMAIL" |
769 |
The e-mail address of the person who built this binary. Has no good |
770 |
default, so should be specified by you. |
771 |
|
772 |
"CPAN" |
773 |
The URL of the CPAN mirror to use (e.g. |
774 |
<http://mirror.netcologne.de/cpan/>). |
775 |
|
776 |
"EXTRA_MODULES" |
777 |
Additional modules installed during staticperl install. Here you can |
778 |
set which modules you want have to installed from CPAN. |
779 |
|
780 |
Example: I really really need EV, AnyEvent, Coro and AnyEvent::AIO. |
781 |
|
782 |
EXTRA_MODULES="EV AnyEvent Coro AnyEvent::AIO" |
783 |
|
784 |
Note that you can also use a "postinstall" hook to achieve this, and |
785 |
more. |
786 |
|
787 |
Variables you might *want* to override |
788 |
"STATICPERL" |
789 |
The directory where staticperl stores all its files (default: |
790 |
~/.staticperl). |
791 |
|
792 |
"PERL_MM_USE_DEFAULT", "EV_EXTRA_DEFS", ... |
793 |
Usually set to 1 to make modules "less inquisitive" during their |
794 |
installation, you can set any environment variable you want - some |
795 |
modules (such as Coro or EV) use environment variables for further |
796 |
tweaking. |
797 |
|
798 |
"PERL_VERSION" |
799 |
The perl version to install - default is currently 5.12.3, but 5.8.9 |
800 |
is also a good choice (5.8.9 is much smaller than 5.12.3, while |
801 |
5.10.1 is about as big as 5.12.3). |
802 |
|
803 |
"PERL_PREFIX" |
804 |
The prefix where perl gets installed (default: $STATICPERL/perl), |
805 |
i.e. where the bin and lib subdirectories will end up. |
806 |
|
807 |
"PERL_CONFIGURE" |
808 |
Additional Configure options - these are simply passed to the perl |
809 |
Configure script. For example, if you wanted to enable dynamic |
810 |
loading, you could pass "-Dusedl". To enable ithreads (Why would you |
811 |
want that insanity? Don't! Use forks instead!) you would pass |
812 |
"-Duseithreads" and so on. |
813 |
|
814 |
More commonly, you would either activate 64 bit integer support |
815 |
("-Duse64bitint"), or disable large files support (-Uuselargefiles), |
816 |
to reduce filesize further. |
817 |
|
818 |
"PERL_CC", "PERL_CCFLAGS", "PERL_OPTIMIZE", "PERL_LDFLAGS", "PERL_LIBS" |
819 |
These flags are passed to perl's Configure script, and are generally |
820 |
optimised for small size (at the cost of performance). Since they |
821 |
also contain subtle workarounds around various build issues, |
822 |
changing these usually requires understanding their default values - |
823 |
best look at the top of the staticperl script for more info on |
824 |
these, and use a ~/.staticperlrc to override them. |
825 |
|
826 |
Most of the variables override (or modify) the corresponding |
827 |
Configure variable, except "PERL_CCFLAGS", which gets appended. |
828 |
|
829 |
Variables you probably *do not want* to override |
830 |
"MAKE" |
831 |
The make command to use - default is "make". |
832 |
|
833 |
"MKBUNDLE" |
834 |
Where staticperl writes the "mkbundle" command to (default: |
835 |
$STATICPERL/mkbundle). |
836 |
|
837 |
"STATICPERL_MODULES" |
838 |
Additional modules needed by "mkbundle" - should therefore not be |
839 |
changed unless you know what you are doing. |
840 |
|
841 |
OVERRIDABLE HOOKS |
842 |
In addition to environment variables, it is possible to provide some |
843 |
shell functions that are called at specific times. To provide your own |
844 |
commands, just define the corresponding function. |
845 |
|
846 |
Example: install extra modules from CPAN and from some directories at |
847 |
staticperl install time. |
848 |
|
849 |
postinstall() { |
850 |
rm -rf lib/threads* # weg mit Schaden |
851 |
instcpan IO::AIO EV |
852 |
instsrc ~/src/AnyEvent |
853 |
instsrc ~/src/XML-Sablotron-1.0100001 |
854 |
instcpan Anyevent::AIO AnyEvent::HTTPD |
855 |
} |
856 |
|
857 |
preconfigure |
858 |
Called just before running ./Configur in the perl source directory. |
859 |
Current working directory is the perl source directory. |
860 |
|
861 |
This can be used to set any "PERL_xxx" variables, which might be |
862 |
costly to compute. |
863 |
|
864 |
postconfigure |
865 |
Called after configuring, but before building perl. Current working |
866 |
directory is the perl source directory. |
867 |
|
868 |
Could be used to tailor/patch config.sh (followed by sh Configure |
869 |
-S) or do any other modifications. |
870 |
|
871 |
postbuild |
872 |
Called after building, but before installing perl. Current working |
873 |
directory is the perl source directory. |
874 |
|
875 |
I have no clue what this could be used for - tell me. |
876 |
|
877 |
postinstall |
878 |
Called after perl and any extra modules have been installed in |
879 |
$PREFIX, but before setting the "installation O.K." flag. |
880 |
|
881 |
The current working directory is $PREFIX, but maybe you should not |
882 |
rely on that. |
883 |
|
884 |
This hook is most useful to customise the installation, by deleting |
885 |
files, or installing extra modules using the "instcpan" or "instsrc" |
886 |
functions. |
887 |
|
888 |
The script must return with a zero exit status, or the installation |
889 |
will fail. |
890 |
|
891 |
ANATOMY OF A BUNDLE |
892 |
When not building a new perl binary, "mkbundle" will leave a number of |
893 |
files in the current working directory, which can be used to embed a |
894 |
perl interpreter in your program. |
895 |
|
896 |
Intimate knowledge of perlembed and preferably some experience with |
897 |
embedding perl is highly recommended. |
898 |
|
899 |
"mkperl" (or the "--perl" option) basically does this to link the new |
900 |
interpreter (it also adds a main program to bundle.): |
901 |
|
902 |
$Config{cc} $(cat bundle.ccopts) -o perl bundle.c $(cat bundle.ldopts) |
903 |
|
904 |
bundle.h |
905 |
A header file that contains the prototypes of the few symbols |
906 |
"exported" by bundle.c, and also exposes the perl headers to the |
907 |
application. |
908 |
|
909 |
staticperl_init (xs_init = 0) |
910 |
Initialises the perl interpreter. You can use the normal perl |
911 |
functions after calling this function, for example, to define |
912 |
extra functions or to load a .pm file that contains some |
913 |
initialisation code, or the main program function: |
914 |
|
915 |
XS (xsfunction) |
916 |
{ |
917 |
dXSARGS; |
918 |
|
919 |
// now we have items, ST(i) etc. |
920 |
} |
921 |
|
922 |
static void |
923 |
run_myapp(void) |
924 |
{ |
925 |
staticperl_init (0); |
926 |
newXSproto ("myapp::xsfunction", xsfunction, __FILE__, "$$;$"); |
927 |
eval_pv ("require myapp::main", 1); // executes "myapp/main.pm" |
928 |
} |
929 |
|
930 |
When your bootcode already wants to access some XS functions at |
931 |
compiletime, then you need to supply an "xs_init" function |
932 |
pointer that is called as soon as perl is initialised enough to |
933 |
define XS functions, but before the preamble code is executed: |
934 |
|
935 |
static void |
936 |
xs_init (pTHX) |
937 |
{ |
938 |
newXSproto ("myapp::xsfunction", xsfunction, __FILE__, "$$;$"); |
939 |
} |
940 |
|
941 |
static void |
942 |
run_myapp(void) |
943 |
{ |
944 |
staticperl_init (xs_init); |
945 |
} |
946 |
|
947 |
staticperl_cleanup () |
948 |
In the unlikely case that you want to destroy the perl |
949 |
interpreter, here is the corresponding function. |
950 |
|
951 |
staticperl_xs_init (pTHX) |
952 |
Sometimes you need direct control over "perl_parse" and |
953 |
"perl_run", in which case you do not want to use |
954 |
"staticperl_init" but call them on your own. |
955 |
|
956 |
Then you need this function - either pass it directly as the |
957 |
"xs_init" function to "perl_parse", or call it as one of the |
958 |
first things from your own "xs_init" function. |
959 |
|
960 |
PerlInterpreter *staticperl |
961 |
The perl interpreter pointer used by staticperl. Not normally so |
962 |
useful, but there it is. |
963 |
|
964 |
bundle.ccopts |
965 |
Contains the compiler options required to compile at least bundle.c |
966 |
and any file that includes bundle.h - you should probably use it in |
967 |
your "CFLAGS". |
968 |
|
969 |
bundle.ldopts |
970 |
The linker options needed to link the final program. |
971 |
|
972 |
RUNTIME FUNCTIONALITY |
973 |
Binaries created with "mkbundle"/"mkperl" contain extra functions, which |
974 |
are required to access the bundled perl sources, but might be useful for |
975 |
other purposes. |
976 |
|
977 |
In addition, for the embedded loading of perl files to work, staticperl |
978 |
overrides the @INC array. |
979 |
|
980 |
$file = staticperl::find $path |
981 |
Returns the data associated with the given $path (e.g. |
982 |
"Digest/MD5.pm", "auto/POSIX/autosplit.ix"), which is basically the |
983 |
UNIX path relative to the perl library directory. |
984 |
|
985 |
Returns "undef" if the file isn't embedded. |
986 |
|
987 |
@paths = staticperl::list |
988 |
Returns the list of all paths embedded in this binary. |
989 |
|
990 |
FULLY STATIC BINARIES - UCLIBC AND BUILDROOT |
991 |
To make truly static (Linux-) libraries, you might want to have a look |
992 |
at buildroot (<http://buildroot.uclibc.org/>). |
993 |
|
994 |
Buildroot is primarily meant to set up a cross-compile environment |
995 |
(which is not so useful as perl doesn't quite like cross compiles), but |
996 |
it can also compile a chroot environment where you can use staticperl. |
997 |
|
998 |
To do so, download buildroot, and enable "Build options => development |
999 |
files in target filesystem" and optionally "Build options => gcc |
1000 |
optimization level (optimize for size)". At the time of writing, I had |
1001 |
good experiences with GCC 4.4.x but not GCC 4.5. |
1002 |
|
1003 |
To minimise code size, I used "-pipe -ffunction-sections -fdata-sections |
1004 |
-finline-limit=8 -fno-builtin-strlen -mtune=i386". The "-mtune=i386" |
1005 |
doesn't decrease codesize much, but it makes the file much more |
1006 |
compressible. |
1007 |
|
1008 |
If you don't need Coro or threads, you can go with "linuxthreads.old" |
1009 |
(or no thread support). For Coro, it is highly recommended to switch to |
1010 |
a uClibc newer than 0.9.31 (at the time of this writing, I used the |
1011 |
20101201 snapshot) and enable NPTL, otherwise Coro needs to be |
1012 |
configured with the ultra-slow pthreads backend to work around |
1013 |
linuxthreads bugs (it also uses twice the address space needed for |
1014 |
stacks). |
1015 |
|
1016 |
If you use "linuxthreads.old", then you should also be aware that uClibc |
1017 |
shares "errno" between all threads when statically linking. See |
1018 |
<http://lists.uclibc.org/pipermail/uclibc/2010-June/044157.html> for a |
1019 |
workaround (And <https://bugs.uclibc.org/2089> for discussion). |
1020 |
|
1021 |
"ccache" support is also recommended, especially if you want to play |
1022 |
around with buildroot options. Enabling the "miniperl" package will |
1023 |
probably enable all options required for a successful perl build. |
1024 |
staticperl itself additionally needs either "wget" (recommended, for |
1025 |
CPAN) or "curl". |
1026 |
|
1027 |
As for shells, busybox should provide all that is needed, but the |
1028 |
default busybox configuration doesn't include comm which is needed by |
1029 |
perl - either make a custom busybox config, or compile coreutils. |
1030 |
|
1031 |
For the latter route, you might find that bash has some bugs that keep |
1032 |
it from working properly in a chroot - either use dash (and link it to |
1033 |
/bin/sh inside the chroot) or link busybox to /bin/sh, using it's |
1034 |
built-in ash shell. |
1035 |
|
1036 |
Finally, you need /dev/null inside the chroot for many scripts to work - |
1037 |
cp /dev/null output/target/dev or bind-mounting your /dev will both |
1038 |
provide this. |
1039 |
|
1040 |
After you have compiled and set up your buildroot target, you can copy |
1041 |
staticperl from the "App::Staticperl" distribution or from your perl |
1042 |
f<bin> directory (if you installed it) into the output/target |
1043 |
filesystem, chroot inside and run it. |
1044 |
|
1045 |
RECIPES / SPECIFIC MODULES |
1046 |
This section contains some common(?) recipes and information about |
1047 |
problems with some common modules or perl constructs that require extra |
1048 |
files to be included. |
1049 |
|
1050 |
MODULES |
1051 |
utf8 |
1052 |
Some functionality in the utf8 module, such as swash handling (used |
1053 |
for unicode character ranges in regexes) is implemented in the |
1054 |
"utf8_heavy.pl" library: |
1055 |
|
1056 |
-Mutf8_heavy.pl |
1057 |
|
1058 |
Many Unicode properties in turn are defined in separate modules, |
1059 |
such as "unicore/Heavy.pl" and more specific data tables such as |
1060 |
"unicore/To/Digit.pl" or "unicore/lib/Perl/Word.pl". These tables |
1061 |
are big (7MB uncompressed, although staticperl contains special |
1062 |
handling for those files), so including them on demand by your |
1063 |
application only might pay off. |
1064 |
|
1065 |
To simply include the whole unicode database, use: |
1066 |
|
1067 |
--incglob '/unicore/**.pl' |
1068 |
|
1069 |
AnyEvent |
1070 |
AnyEvent needs a backend implementation that it will load in a |
1071 |
delayed fashion. The AnyEvent::Impl::Perl backend is the default |
1072 |
choice for AnyEvent if it can't find anything else, and is usually a |
1073 |
safe fallback. If you plan to use e.g. EV (POE...), then you need to |
1074 |
include the AnyEvent::Impl::EV (AnyEvent::Impl::POE...) backend as |
1075 |
well. |
1076 |
|
1077 |
If you want to handle IRIs or IDNs (AnyEvent::Util punycode and idn |
1078 |
functions), you also need to include "AnyEvent/Util/idna.pl" and |
1079 |
"AnyEvent/Util/uts46data.pl". |
1080 |
|
1081 |
Or you can use "--usepacklists" and specify "-MAnyEvent" to include |
1082 |
everything. |
1083 |
|
1084 |
Carp |
1085 |
Carp had (in older versions of perl) a dependency on Carp::Heavy. As |
1086 |
of perl 5.12.2 (maybe earlier), this dependency no longer exists. |
1087 |
|
1088 |
Config |
1089 |
The perl -V switch (as well as many modules) needs Config, which in |
1090 |
turn might need "Config_heavy.pl". Including the latter gives you |
1091 |
both. |
1092 |
|
1093 |
Term::ReadLine::Perl |
1094 |
Also needs Term::ReadLine::readline, or "--usepacklists". |
1095 |
|
1096 |
URI URI implements schemes as separate modules - the generic URL scheme |
1097 |
is implemented in URI::_generic, HTTP is implemented in URI::http. |
1098 |
If you need to use any of these schemes, you should include these |
1099 |
manually, or use "--usepacklists". |
1100 |
|
1101 |
RECIPES |
1102 |
Just link everything in |
1103 |
To link just about everything installed in the perl library into a |
1104 |
new perl, try this (the first time this runs it will take a long |
1105 |
time, as a lot of files need to be parsed): |
1106 |
|
1107 |
staticperl mkperl -v --strip ppi --incglob '*' |
1108 |
|
1109 |
If you don't mind the extra megabytes, this can be a very effective |
1110 |
way of creating bundles without having to worry about forgetting any |
1111 |
modules. |
1112 |
|
1113 |
You get even more useful variants of this method by first selecting |
1114 |
everything, and then excluding stuff you are reasonable sure not to |
1115 |
need - bigperl <http://staticperl.schmorp.de/bigperl.html> uses this |
1116 |
approach. |
1117 |
|
1118 |
Getting rid of netdb functions |
1119 |
The perl core has lots of netdb functions ("getnetbyname", |
1120 |
"getgrent" and so on) that few applications use. You can avoid |
1121 |
compiling them in by putting the following fragment into a |
1122 |
"preconfigure" hook: |
1123 |
|
1124 |
preconfigure() { |
1125 |
for sym in \ |
1126 |
d_getgrnam_r d_endgrent d_endgrent_r d_endhent \ |
1127 |
d_endhostent_r d_endnent d_endnetent_r d_endpent \ |
1128 |
d_endprotoent_r d_endpwent d_endpwent_r d_endsent \ |
1129 |
d_endservent_r d_getgrent d_getgrent_r d_getgrgid_r \ |
1130 |
d_getgrnam_r d_gethbyaddr d_gethent d_getsbyport \ |
1131 |
d_gethostbyaddr_r d_gethostbyname_r d_gethostent_r \ |
1132 |
d_getlogin_r d_getnbyaddr d_getnbyname d_getnent \ |
1133 |
d_getnetbyaddr_r d_getnetbyname_r d_getnetent_r \ |
1134 |
d_getpent d_getpbyname d_getpbynumber d_getprotobyname_r \ |
1135 |
d_getprotobynumber_r d_getprotoent_r d_getpwent \ |
1136 |
d_getpwent_r d_getpwnam_r d_getpwuid_r d_getsent \ |
1137 |
d_getservbyname_r d_getservbyport_r d_getservent_r \ |
1138 |
d_getspnam_r d_getsbyname |
1139 |
# d_gethbyname |
1140 |
do |
1141 |
PERL_CONFIGURE="$PERL_CONFIGURE -U$sym" |
1142 |
done |
1143 |
} |
1144 |
|
1145 |
This mostly gains space when linking statically, as the functions |
1146 |
will likely not be linked in. The gain for dynamically-linked |
1147 |
binaries is smaller. |
1148 |
|
1149 |
Also, this leaves "gethostbyname" in - not only is it actually used |
1150 |
often, the Socket module also exposes it, so leaving it out usually |
1151 |
gains little. Why Socket exposes a C function that is in the core |
1152 |
already is anybody's guess. |
1153 |
|
1154 |
AUTHOR |
1155 |
Marc Lehmann <schmorp@schmorp.de> |
1156 |
http://software.schmorp.de/pkg/staticperl.html |
1157 |
|