Storing Modules Local

coreolyn has asked for the wisdom of the Perl Monks concerning the following question:

Hello fellow monks. I'm trying to help answer a question that's currently on the CGI-Mailing list, that I know I'm going to need to find the answer for myself in the next few weeks. It is as follows:

> This is the picture: I want to package my Perl application
> that relies on various other Perl Modules (CGI, DBI, DBD etc..)
> into a single distribution. System users should be able to install
> my application without having root access to the system. This
> means that all the supporting modules should be installed locally.
>
> I know it's possible to call the MakeMaker's Makefile.PL script
> with the PREFIX argument that defines the installation path for
> the modules. This seems to work fine for 'normal' modules but
> gives these errors for XS modules, like DBI:
>
> Can't load '../lib/lib/site_perl//i386-linux/auto/DBI/DBI.so' for mo
+dule
> DBI: ../lib/lib/site_perl//i386-linux/auto/DBI/DBI.so: undefined sym
+bol:
> dirty at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169.
>
>  at ../lib/lib/site_perl//DBI.pm line 158
> BEGIN failed--compilation aborted at ../lib/lib/site_perl//DBI.pm li
+ne
> 158.
>
> This is just one example, but all the modules that rely on C extensi
+ons
> seem to give these undefined symbol errors.
>
> Anyone has a hint on this?
[download]

Any help would be appreciated.

coreolyn Duct tape devotee.
-- That's OO perl, NOT uh-oh perl !-)

Comment on Storing Modules Local Download Code

Replies are listed 'Best First'.
Re (tilly) 1: Storing Modules Local by tilly (Archbishop) on Aug 21, 2000 at 19:39 UTC
Given that merlyn confirmed my suspicion about what you want being intractable, a workaround is to investigate the CPAN module. It isn't hard to create a bundle for what people want, or to set up your local environment with PERL5LIB and CPAN so you can install modules for yourself without root access. If people go through that work then they can install anything they want as themselves (assuming that they have room and a C compiler) and let CPAN worry about the dependencies. Not totally pleasant, but workable. FWIW the workaround that ActiveState uses is to compile everything with a veeerrrry loooonnnng paaattthhh. Then during installation they search the binaries and replace that with the real one. A bad hack to be sure, but Sarathy claims nobody has noticed yet...	[reply]
Re: Storing Modules Local by merlyn (Sage) on Aug 21, 2000 at 19:29 UTC
Yeah, that's an intractable problem. The binaries contain a path that gets compiled in during the build. There's an ongoing "to do" in the Perl developer list to figure out ways around this. Hmm. You might get some relief if you set `LD_LIBRARY_PATH`, but I'm just drawing at straws now. -- Randal L. Schwartz, Perl hacker	[reply]
RE: Re: Storing Modules Local by coreolyn (Parson) on Aug 21, 2000 at 19:57 UTC
Ug! Well is there anything a lowly scribe could do to push this 'todo' along, Or is that beyond the scope of a 2 year old perl hack? coreolyn Duct tape devotee. -- That's OO perl, NOT uh-oh perl !-)	[reply]
RE: RE: Re: Storing Modules Local by merlyn (Sage) on Aug 21, 2000 at 20:01 UTC
It probably won't get any attention except in the context of the Perl6 development, and if I recall, that was already one of the Perl6 RFCs being considered for implementation. So, in a few years when Perl6 is released, you'll have a solution. Until then, it's use fixed pathnames, or recompile from source. -- Randal L. Schwartz, Perl hacker	[reply]
RE: Storing Modules Local by princepawn (Parson) on Aug 22, 2000 at 21:40 UTC
I had some modules that seemed to require installation in the /usr hierarchy this morning. But then, I noticed that the modules worked fine with 'make test' so I asked what is make test doing that I am not? I noticed that the invocation of Perl was using -Ilib/blib so that the use of the module would occur from the local directory. This may be of some help in your case.	[reply]