view release on metacpan or  search on metacpan

bin/staticperl  view on Meta::CPAN

      chmod u+w "$PERL_PREFIX"/lib/auto/Net/SSLeay/extralibs.ld
      echo " -ldl" >>"$PERL_PREFIX"/lib/auto/Net/SSLeay/extralibs.ld
   }

=item Pango

In addition to the C<MAN3PODS> problem in Glib, Pango also routes around
L<ExtUtils::MakeMaker> by compiling its files on its own. F<staticperl>
tries to patch L<ExtUtils::MM_Unix> to route around Pango.

=item Term::ReadLine::Perl

Also needs L<Term::ReadLine::readline>, or C<--usepacklists>.

=item URI

URI implements schemes as separate modules - the generic URL scheme is
implemented in L<URI::_generic>, HTTP is implemented in L<URI::http>. If
you need to use any of these schemes, you should include these manually,
or use C<--usepacklists>.

=back

=head2 RECIPES

=over 4

=item Just link everything in

To link just about everything installed in the perl library into a new
perl, try this (the first time this runs it will take a long time, as a
lot of files need to be parsed):

   staticperl mkperl -v --strip ppi --incglob '*'

If you don't mind the extra megabytes, this can be a very effective way of
creating bundles without having to worry about forgetting any modules.

You get even more useful variants of this method by first selecting
everything, and then excluding stuff you are reasonable sure not to need -
L<bigperl|http://staticperl.schmorp.de/bigperl.html> uses this approach.

=item Getting rid of netdb functions

The perl core has lots of netdb functions (C<getnetbyname>, C<getgrent>
and so on) that few applications use. You can avoid compiling them in by
putting the following fragment into a C<preconfigure> hook:

   preconfigure() {
      for sym in \
         d_getgrnam_r d_endgrent d_endgrent_r d_endhent \
         d_endhostent_r d_endnent d_endnetent_r d_endpent \
         d_endprotoent_r d_endpwent d_endpwent_r d_endsent \
         d_endservent_r d_getgrent d_getgrent_r d_getgrgid_r \
         d_getgrnam_r d_gethbyaddr d_gethent d_getsbyport \
         d_gethostbyaddr_r d_gethostbyname_r d_gethostent_r \
         d_getlogin_r d_getnbyaddr d_getnbyname d_getnent \
         d_getnetbyaddr_r d_getnetbyname_r d_getnetent_r \
         d_getpent d_getpbyname d_getpbynumber d_getprotobyname_r \
         d_getprotobynumber_r d_getprotoent_r d_getpwent \
         d_getpwent_r d_getpwnam_r d_getpwuid_r d_getsent \
         d_getservbyname_r d_getservbyport_r d_getservent_r \
         d_getspnam_r d_getsbyname
         # d_gethbyname
      do
         PERL_CONFIGURE="$PERL_CONFIGURE -U$sym"
      done
   }

This mostly gains space when linking statically, as the functions will
likely not be linked in. The gain for dynamically-linked binaries is
smaller.

Also, this leaves C<gethostbyname> in - not only is it actually used
often, the L<Socket> module also exposes it, so leaving it out usually
gains little. Why Socket exposes a C function that is in the core already
is anybody's guess.

=back

=head1 ADDITIONAL RESOURCES

Some guy has made a repository on github
(L<https://github.com/gh0stwizard/staticperl-modules>) with some modules
patched to build with staticperl.

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://software.schmorp.de/pkg/staticperl.html