svn commit: r123814 - /perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod

[st...@apache.org]

Author: stas
Date: Fri Dec 31 11:01:39 2004
New Revision: 123814

URL: http://svn.apache.org/viewcvs?view=rev&rev=123814
Log:
notes on libperl.(a|so)
Contributed by: William McKee <wi...@knowmad.com>

Modified:
   perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod

Modified: perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod
Url: http://svn.apache.org/viewcvs/perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod?view=diff&rev=123814&p1=perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod&r1=123813&p2=perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod&r2=123814
==============================================================================
--- perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod	(original)
+++ perl/modperl/docs/trunk/src/docs/1.0/guide/install.pod	Fri Dec 31 11:01:39 2004
@@ -681,9 +681,60 @@
   mod_perl.o(.text+0x13b): undefined reference to `Perl_av_undef'
   [more errors snipped]
 
-This happens when you have Perl built statically linked, with no
-shared I<libperl.a>.  Build a dynamically linked Perl (with
-I<libperl.a>) and the problem will disappear.
+This happens when you have a statically linked perl build
+(i.e. without a shared I<libperl.so> library).  Build a dynamically
+linked perl (with I<libperl.so>) and the problem will disappear. See
+the "Building a shared Perl library" section from the I<INSTALL> file
+that comes with Perl source.
+
+=for html Also see <a
+href="http://modperlbook.org/html/ch15_04.html">Chapter 15.4 - Perl
+Build Options"</a> from <a href="http://modperlbook.org/">Practical
+mod_perl</a>.
+
+=head4 Further notes on libperl.(a|so)
+
+Library files such as I<libfoo.a> are archives that are used at
+linking time - these files are completely included in the final
+application that linked it.
+
+Whereas I<libfoo.so> indicates that it's a shared library. At the
+linking time the application only knows which library it wants. Only
+at the loading time (runtime) that shared library will be loaded.
+
+One of the benefits of using a shared library, is that it's loaded
+only once. If there are two application linking to F<libperl.so> that
+run at the same time, only the first application will need to load
+it. The second application will share that loaded library (that
+service is provided by the OS kernel). In the case of static
+I<libfoo.a>, it'll be loaded as many times as there are applications
+that included it, thus consuming more memory. Of course this is not
+the only benefit of using shared libs.
+
+In mod_perl 1.0, the library file is unfortunately named
+F<libperl.(so|a)>. So you have F<libperl.(so|a)> which is perl, and
+you have F<libperl.(so|a)> which is modperl. You are certainly looking
+at the modperl version of F<libperl.a> if you find it in the apache
+directory. perl's F<libperl.(so|a)> lives under the perl tree (e.g. in
+F<5.8.6/i686-linux/CORE/libperl.so>).
+
+Some distributions (notably Debian) have chosen to put F<libperl.so>
+and F<libperl.a> into the global library loader path (e.g.,
+F</usr/lib>) which will cause linking problems when compiling mod_perl
+(if compiling against static perl), in which case you hould move aside
+the F<libperl.a> while building mod_perl or else will likely encounter
+further errors. If building against the dynamic perl's F<libperl.so>,
+you may have similar problems but at startup time. It's the best to
+get rid of perl that installs its libs into F</usr/lib> (or similar)
+and reinstall a new perl, which puts its library under the perl tree.
+
+
+
+
+
+
+
+
 
 =head2 mod_perl Building (make)
 

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org