Sanity check: statically linking binary extensions like GD in to httpd

[Barrie Slaymaker <ba...@slaysys.com>]

I'm seeking a sanity check on statically linked binary extensions in
with httpd.  I've built what I want, but the build is not easily
automatable, and I'm hoping I missed an easy alternative somewhere.

Background: we have a .png that we want to generate on the fly with up
to several thousand filled circles, dots, lines etc., using GD.pm, so
I've shoe horned it and libpng into the httpd to get a minor performance
improvement (we want to put this image on almost every page, and caching
can help, but we need to be able to draw it *fast*, and all those calls
in to a dynamically linked library cause noticable overhead[1].) I'd
also like to write this up.

First, I tried to build GD as a static extension:

   perl Makefile.PL LINKTYPE=static
   make 
   make test
	 ...snip...
   cat /usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/extralibs.ld >> blib/arch/auto/GD/extralibs.all
   cat /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/extralibs.ld >> blib/arch/auto/GD/extralibs.all
   cat blib/arch/auto/GD/extralibs.ld >> blib/arch/auto/GD/extralibs.all
   cc -L/usr/local/lib -rdynamic -o perl -O2 ./perlmain.o GD.o blib/arch/auto/GD/GD.a /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/libapreq.a /usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/DynaLoader.a /usr/local/lib/perl5/5.6.1/i686-linux/CORE/libperl.a `cat blib/arch/auto/GD/extralibs.all` -lnsl -ldl -lm -lc -lposix -lcrypt -lutil 
   ./perlmain.o: In function `xs_init':
   ./perlmain.o(.text+0x9f): undefined reference to `boot_libapreq'
   collect2: ld returned 1 exit status
      ...snip...

Doing this attempts to build a static perl, which fails with the below
error message.  It seems that the LINKTYPE=static is forcing ExtUtils to
think that *all* static-looking extensions in site_perl/ should be
static, not just those mentioned in $Config{static_exts} (which is ' '
here).  I'm assuming that libapreq isn't primed to be a static extension
because I'm running a dynamic perl, but this may be a bug.  Whether or
not it's a bug, it seems like it's awkward.

So I mved site_perl off to the side for a moment and it builds and
installs fine.  libapreq is not statically linked in to my perl binary
because it's only needed for mod_perl use, and mod_perl links it
(statically) in to the httpd.

QUESTION 1: how can I build a static extension for use with mod_perl
that you *don't* want in your normal perl, and how do I get it to ignore
dynamic extension dependancies like the libapreq one?  Building a perl
by another name, like gdperl, works (after the mv site_perl), but
doesn't build an equivalent libgdperl.a (see question 2, below).
"gdperl" is a nice abbreviation though ;).

Anyway, after getting GD.a installed in to site_perl (and giving up on
gdperl, since no libgdperl.a was built) I configure mod_perl like so:

perl Makefile.PL \
    APACHE_SRC=../apache-1.3.22/src \
    DO_HTTPD=1 \
    USE_APACI=1 \
    EVERYTHING=1 \
    PERL_STATIC_EXTS="GD" \
    APACHE_PREFIX=$HOME/gdwww \
    PREFIX=$HOME/gdwww

and the build fails because GD.a isn't being linked in, and libperl.a
doesn't contain the object modules from GD.a.

** QUESTION 2: how to get libperl.a to contain the guts of GD?  Or,
alternatively, how do I tell mod_perl that I want GD.a linked in
(without hacking apaci/perl.module)? Even when I do a make -f
Makefile.aperl inst_perl, no new libperl.a is installed.  I could do the
old trick of cpio-ing GD in to the perl distro, but there must be a
better way I'm not seeing.  PERL

So, I tweaked mod_perl's apaci/perl.module to have the line:

    LIBS="$LIBS /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/GD/GD.a -lgd -ljpeg -lpng" 

near the end and I get a nice, shiny statically linked httpd with all of
the require libs.  YAY!

** QUESTION 3: What is the recommended way to link in external .a and .o
modules like libpng.a?

Hopefully, there's a left turn in Albuquerque I should have taken that
someone can point out to me...

Thanks,

Barrie

[1] which means we may head to C for some of the core routines, but that
just moves the linking issues up a level.