Re: [mp1] Linking confusion

[prev] [thread] [next] [Date index for 2004/12/31]

--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Thanks for the clear explanation of *.a and *.so files, Stas. I'm
starting to grok how it works together.

I've attached the diff to the install docs to this message which
incorporates some of your notes about .so and .a files. I found this
information hard to find while browsing Google, Perlmonks and the
modperl docs. I hope that you will include them in some form.


Thanks,
William

        -- 
        Knowmad Services Inc.
http://www.knowmad.com

--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="install.pod.diff"

--- /tmp/install.pod.orig	2004-12-31 10:04:39.000000000 -0500
+++ /tmp/install.pod.wlm	2004-12-31 11:58:30.000000000 -0500
@@ -681,9 +681,38 @@
   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 perl built statically linked, with no
+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 sources.  Also
+see L<"Chapter 15.4  - Perl Build
+Options"|http://modperlbook.org/html/ch15_04.html>; from I<Practical mod_perl>.
+
+=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.
+
+I<libfoo.so> is a shared library. At the linking time the application only
+knows which library it wants. Only at the loading time (runtime) that
+library will be loaded.
+
+One of the benefits of using a shared library, is that it's loaded only once,
+any application using the same library will not need load it, it'll be shared
+(a service provided by the 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_perl1, the library file is unfortunately named libperl.(so|a). So you
+have libperl.(so|a) which is perl, and you have libperl.(so|a) which is
+modperl. You are certainly looking at the modperl version of libperl.a if you
+find it in the apache directory. perl's libperl.(so|a) lives under something
+like 5.8.6/i686-linux/CORE/.
+
+Some distributions (notably Debian) have chosen to put libperl.so into the
+library path (e.g., /usr/lib) which will cause linking problems when compiling
+mod_perl. You should delete or move aside the libperl.so while building
+mod_perl or else will likely encounter further errors.
 
 =head2 mod_perl Building (make)
 


--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--rJwd6BRFiFCcLxzm--