4. Could you explain a little more about the change you made?
Let's say your perl is build using a shared library libperl.so, which normally resides at /usr/local/lib/perl5/5.8.0/i386-freebsd/CORE/libperl.so. When you are linking a shared perl library you need to specify:
-L/usr/local/lib/perl5/5.8.0/i386-freebsd/CORE/ -lperl
as the arguments to the linker. It will look for libperl.so under the directories starting with the -L option. Running:
% perl-5.8.1-ithread-nouseshrplib -MExtUtils::Embed -e ldopts
should give us the linking options. If perl is dynamically linked it will give us the above two arguments (-L/path -lperl) among other flags.
Now if you perl is built statically, its static library libperl.a resides in the same directory. Though the linker expects a relative to the current directory or a full path to the static library. Therefore it wants
/usr/local/lib/perl5/5.8.0/i386-freebsd/CORE/libperl.a
instead of '-L/path -lperl'. So all I did is giving the linker what it wants. and the patch that I sent does exactly that:
s{ -L/usr/local/lib/perl5/5.8.0/i386-freebsd/CORE/ -lperl }
{ /usr/local/lib/perl5/5.8.0/i386-freebsd/CORE/libperl.a }x;Hope this explains the issue.
And don't get confused with modules/perl/libperl.a which is a mod_perl static library and unrelated to this problem. This source of confusion has been fixed in mod_perl 2, where the mod_perl libraryis called mod_perl.(so|a). It can't be fixed in mp1, I think because that's how Apache wants it to be named.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
