You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Barrie Slaymaker <ba...@slaysys.com> on 2001/11/08 19:18:18 UTC
Sanity check: statically linking binary extensions like GD in to httpd
Sorry for the fwd, was hoping somebody might cluebat me with something I
missed; never got any responses; so I thought I'd try over on this
list...
Bottom line question is: is there any way to statically link something
like GD (and thus lipjpeg, libpng, etc) in to the httpd without having
to either hack apaci/perl.module?
Then there's the issue that LINKTYPE=static tries to suck things it
shouldn't out of site_perl, which leads me to beleive I've missed
something.
Thanks,
Barrie
----- Forwarded message from Barrie Slaymaker <ba...@slaysys.com> -----
Date: Thu, 25 Oct 2001 15:01:44 -0400
From: Barrie Slaymaker <ba...@slaysys.com>
User-Agent: Mutt/1.2.5i
To: modperl@apache.org
Subject: Sanity check: statically linking binary extensions like GD in to
httpd
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.
----- End forwarded message -----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Sanity check: statically linking binary extensions like GD in to httpd
Posted by Barrie Slaymaker <ba...@slaysys.com>.
On Tue, Nov 13, 2001 at 03:51:33PM -0600, Salvador Ortiz Garcia wrote:
>
> Haven't seen the original post (I'm in troubles with my server), but the
> standard solution when building an static perl extension without MakeMaker
> trying to link in other extensions is:
>
> $ perl Makefile.PL INCLUDE_EXT=''
Thanks.
I'm not building a perl+GD+libpng+... first is the issue here. I am
trying to add it when linking httpd+libperl(mod_perl)+...
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Sanity check: statically linking binary extensions like GD in
to httpd
Posted by Salvador Ortiz Garcia <so...@msg.com.mx>.
On Tue, 13 Nov 2001, Doug MacEachern wrote:
> On Thu, 8 Nov 2001, Barrie Slaymaker wrote:
>
> > ./perlmain.o: In function `xs_init':
> > ./perlmain.o(.text+0x9f): undefined reference to `boot_libapreq'
>
> haven't had a change to digest all this, but you should rm the libapreq.a
> from your site_perl tree to fix this problem.
>
> as for linking libpng.a instead of libpng.so, you can try linker flags
> such as: -Bstatic -lpng -Bdynamic
> -Bstatic for everything hasn't worked for me in the past, i think the
> above will only link libpng static. or, create a directory without the
> .so', like /usr/local/lib/static and symlink your *.a's into there, and
> use -L/usr/local/lib/static -lpng -lfoo
Haven't seen the original post (I'm in troubles with my server), but the
standard solution when building an static perl extension without MakeMaker
trying to link in other extensions is:
$ perl Makefile.PL INCLUDE_EXT=''
Regards
Salvador Ortiz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Sanity check: statically linking binary extensions like GD in
to httpd
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 8 Nov 2001, Barrie Slaymaker wrote:
> ./perlmain.o: In function `xs_init':
> ./perlmain.o(.text+0x9f): undefined reference to `boot_libapreq'
haven't had a change to digest all this, but you should rm the libapreq.a
from your site_perl tree to fix this problem.
as for linking libpng.a instead of libpng.so, you can try linker flags
such as: -Bstatic -lpng -Bdynamic
-Bstatic for everything hasn't worked for me in the past, i think the
above will only link libpng static. or, create a directory without the
.so', like /usr/local/lib/static and symlink your *.a's into there, and
use -L/usr/local/lib/static -lpng -lfoo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org