On Thu, Nov 06, 2003 at 06:02:11AM -0800, Michael G Schwern wrote:
> On Thu, Nov 06, 2003 at 01:48:20PM +0100, Jochen Eisinger wrote:
> > Michael G Schwern wrote:
> > > What is rpath anyway?
> > the path where the elf loader will search for libraries. A tidy system
> > shouldn't need a /etc/ld.so.conf and stuff since every elf file already
> > contains enough information where to search for dynamic libraries. The
> > rpath is set with -Wl,-R or -R or -rpath
> >
> > It's the path where the module will search for libperl.so in this case.
> >
> > > And why would anything rely on $(INSTALLARCHLIB)/CORE
> > > being in it?
> > dunno, maybe somebody wants his or her own libperl or something...
> >
> > > I wish I knew who originally patched this.
> >
> > [EMAIL PROTECTED] patched it into the 5.6.1 NetBSD package.
>
> Ok then, we'll ask him.
>
> Hi. We're discussing this bit in ExtUtils::MM_Unix.
>
> if ($Is_NetBSD && $Config{'useshrplib'}) {
> # Use nothing on static perl platforms, and to the flags needed
> # to link against the shared libperl library on shared perl
> # platforms. We peek at lddlflags to see if we need -Wl,-R
> # or -R to add paths to the run-time library search path.
> if ($Config{'lddlflags'} =~ /-Wl,-R/) {
> $libs .= ' -L$(PERL_INC) -Wl,-R$(INSTALLARCHLIB)/CORE -lperl';
> } elsif ($Config{'lddlflags'} =~ /-R/) {
> $libs .= ' -L$(PERL_INC) -R$(INSTALLARCHLIB)/CORE -lperl';
> }
> }
>
> It appears that $(INSTALLARCHLIB)/CORE is a mistake. INSTALLARCHLIB
> is where the architecture specific libraries are going to be installed.
> By default this is $(PERL_ARCHLIB) but it can be changed if the
> user sets it explicitly or implicitly with something like PREFIX. This
> means the files in CORE won't be found like the Perl headers and shared
> libraries.
>From the description above, I'm unclear as to the difference between
INSTALLARCHLIB and PERL_ARCHLIB. The final place where libperl.so
is installed should definitely be added to the rpath.
> We're trying to figure out if we should just replace INSTALLARCHLIB with
> PERL_ARCHLIB, or put both INSTALLARCHLIB and PERL_ARCHLIB in. It seems
> like the former is correct.
>
> Did you deliberately intend to use INSTALLARCHLIB for some reason or did
> you accidentally use it instead of PERL_ARCHLIB?
I apologize if my understanding of INSTALLARCHLIB and PERL_ARCHLIB
may be flawed, and would appreciate any enlightenment that you can
offer.
As I understand it, PERL_ARCHLIB is something that the user can modify
in configuring Perl modules that use MakeMaker.pm. This allows
installing the arch-dependent *.so files of the Perl module into a
location outside of the normal Perl directory hierarchy if the user so
chooses. However, we still need to ensure that these *.so files have
the directory containing libperl.so in their rpaths, which is why I
think that INSTALLARCHLIB is the correct thing to add to the rpath.
There is also the extra complication that the *.so files for a single
Perl module may be linked against each other, in which case it sounds
like we should also add PERL_ARCHLIB to the rpath as well.
FYI, The code fragment you excerpted is largely a hack, since there's
no actual guarantee that $Config{'lddlflags'} contains any rpath
directives for the compiler/linker. This was simply the easiest way
to "fix" a pervasive problem on NetBSD systems where Perl *.so files
weren't properly linked against libperl.so, and where we (pkgsrc
developers) could guarantee that lddlflags would contain at least
one rpath directive appropriate for that NetBSD platform. If you're
looking for a better way to redo this fix, I'm happy to help. I'm
much more familiar with the MakeMaker.pm code and with Perl coding
in general than I was when I originally offered this patch to Jarkko
<[EMAIL PROTECTED]> for inclusion into Perl 5.6.1.
Cheers,
-- Johnny Lam <[EMAIL PROTECTED]>
