Re: static linking vs DSO linking
Hi Randal, On 11 Jun 2003, Randal L. Schwartz wrote: > Am I crazy for suggesting that DSO doesn't really gain you much...? 'Sfunny you should say that... > Also, has anyone gotten experience with AddModule mod_perl but keeping > the front-end's mod_perl tasks to a minimum, and therefore the memory > footprint very small? Never had to worry about it a great deal, I usually just throw RAM or boxes at it. Maybe you could have a look at Squid or something? 73, Ged. -- On Tue, 10 Jun 2003, Ged Haywood wrote: > On Tue, 10 Jun 2003, Forrest Aldrich wrote: > > > I wonder if this will affect anything else, especially other > > things that require DSO support. ? > > Have you got the Eagle Book? You need > > --enable-module=so > > in your configure arguments to put mod_so into Apache, mod_so allows > Apache to load shared objects. > > > What does --enable-shared=max imply to Apache... > > make as much as possible as shared objects, the idea being to make the > resulting binary smaller. It won't save any memory if you run it with > tons of modules loaded, so it's probably more trouble than it's worth. > Which is my opinion of DSO generally. I always build static if I can. >
static linking vs DSO linking
At a recent client, I had the mandate to develop a front/back server setup, with the front being a thin mod_proxy setup and the back being a fat mod_perl setup. One of the things I noticed while compiling and deploying Apache on Solaris via the pmap command is that the static linking and selective loading (via LoadModule) didn't really save me that much stuff... only the AddModule selected whether the module had been activated, and therefore allocated its private memory. Has anyone else seen this? Am I crazy for suggesting that DSO doesn't really gain you much, and a simple selective AddModule is enough? Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? I want the backend's mod_perl usage to be fat: that's the whole point of the divergence. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
