develooper Front page | perl.perl5.porters | Postings from April 2001

Re: Relocatable perl

Thread Previous | Thread Next
Alan Burlison
April 30, 2001 09:14
Re: Relocatable perl
Message ID:
Graham Barr wrote:

> Is that the real path to the executable, or the path which it was invoked
> by ?

The real path, specifically the dirname(3C) of the associated objects
realpath(3C).  The only restriction is that if you invoke the executable via
a link it needs to be a symlink rather than a hard link.

> > I suspect that to make this work I'd have to make all of those #defines into
> > dynamic strings, and tweak them at startup.  Does this seem correct?  Where
> Seems right to me.
> > would I put them?  Globals?
> They get put into @INC

No, I don't mean that, I mean the C #defines would have to become global
char*  because they are used in more than one place inside the interpreter.

> >  This would only work if the above variables all
> > had a common directory prefix - if someone decided for some reason to tell
> > Configure they wanted SITELIB_EXP on a completely different filesystem there
> > would be no common directory prefix to twiddle.
> Just define a special token that gets replaced.

This happens at run-time - how would that work?

> > Is this really worth the effort?
> Yes. I remember when I was working at TI. They shipped a kit to customers for
> development, but they could not depend on the custmer having the correct version
> of perl, so they shipped it with the kit.
> However the kit could be installed anywhere, so all scripts had to be wrapped
> so they could find the perl executable. It was a mess.

Initially I would probably just provide this as a patch to 5.6.1, and
include it in the 5.6.1 we ship with

Alan Burlison

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About