|Don't ask to ask, just ask|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
Static linking is almost never the answer, but there is one exception which is if you need bindings to an external system that somehow does not give you position-independent code. An example for many years was arsperl.
If you want to go with static linking then ysth's post is the answer.
If a system does not support dynamic loading (Is SCO really like this? -- that would IMHO almost qualify as a dinosaur-OS ;), I believe that any XS glue must be compiled statically. If the glue needs shared libraries then they will be called "statically" by the system dynamic loader (at executable startup time usually, but compiler flags can normally enable some on-demand mode) in the usual way i.e the way the system will load the libc shared library.
Still you have another option: Build a perl with all dependencies inside the distribution tree. I have been doing that for years on HP-UX.
You have to repeat the process for any client path where you plan to have perl+modules installed. Yes this involves rebuilding all the modules...
On HP-UX I use a dirty trick to speed up the process. suppose I built all my modules for /var/tmp/opt/perl588. I want them now for /opt/perl588. The install process takes care of the perl core. So for the modules I have to care about a few things:
The result is a tarrable perl dist that you can install almost anywhere (it has two parts the perl dir + special dirs needed by modules).
Note that I do not like shared libraries with dependencies on other shared libraries. It is just too confusing. When I build my own shared libraries I try to avoid that. The responsability of knowing with what to link should be the responsability of the executable. Of course bindings are another matter.
Nicholas Clark did some work on making perl more relocatable (IIRC was done after 5.8.8). You can browse the p5p archives to see the details.cheers --stephan
P.S there might be licensing issues...
In reply to Re: static linking demanded