view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        you cna use the following snippet in your "postinstall" hook which
        patches Net::SSLeay after installation, which happens to work most
        of the time:

           postinstall() {
              # first install it
              instcpan Net::SSLeay
              # then add -ldl for future linking
              chmod u+w "$PERL_PREFIX"/lib/auto/Net/SSLeay/extralibs.ld
              echo " -ldl" >>"$PERL_PREFIX"/lib/auto/Net/SSLeay/extralibs.ld
           }

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

    Term::ReadLine::Perl
        Also needs Term::ReadLine::readline, or "--usepacklists".

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

  RECIPES
    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 - bigperl <http://staticperl.schmorp.de/bigperl.html> uses this
        approach.

    Getting rid of netdb functions
        The perl core has lots of netdb functions ("getnetbyname",
        "getgrent" and so on) that few applications use. You can avoid
        compiling them in by putting the following fragment into a
        "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 "gethostbyname" in - not only is it actually used
        often, the 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.

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

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