On Wed, Nov 04, 2009 at 01:11:29PM +0000, Nicholas Clark wrote:
>  On Wed, Nov 04, 2009 at 01:01:32PM +0000, Tim Bunce wrote:
>  
>  > It seems to me that -Duseshrplib conflates two things that should be
>  > separate: a) the building and installing of a shared libperl, and
>  > b) linking the perl executable against it instead of the libperl.a.

After posting my earlier message that I realized that it might not be so
straight forward. If an app wants to embed perl using the shared libperl
then it'll naturally want to use extensions.

That raises the binary compatibility issue: are extensions built for
a non-shared perl compatible with the shared libperl?

>  Should we therefore compile all object code with -fPIC, with the same
>  object files linked statically to the perl executable, and used in the
>  shared library?
>  
>  Or should we compile everything twice, once with -fPIC and once without,
>  using the -fPIC code for the shared library, and the normal code for the
>  executable?
>  
>  The distinction between -fPIC and not matters on at least x86_64

I don't know what the issues/trade-offs are well enough to answer that.

Does using -fPIC but then static linking cause a performance loss on
major platforms (or can the use of PIC code be 'undone' during the
static linking, perhaps with an extra ld option)?

Since compiling everything twice would work, I think the binary
compatibility of extensions is a greater issue at this stage.
Any thoughts on that?

Tim.