On Wed, 4 Nov 2009, Tim Bunce wrote:

>  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?

I can't think of any reason why they wouldn't be.  The extensions are all 
compiled with -fPIC (or equivalent) whether or not there's a shared 
libperl.  I can't think of any relevant flags that are changed in the 
build process.

This does remind me, however, that the Config keys used for building with 
an embedding perl *do* change depending on useshrplib. In particular, 
linking the app would now require an appropriate -rpath flag, but perl 
wouldn't have been built with that flag.

>  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)?

The benchmark data in INSTALL is mine; I'd estimate it's from early 1996.
Newer tests would certainly be welcome.  Timing the test suite is no 
longer suitable, since there are so many sleeps() and other things that 
wait on I/O.

-- 
    Andy Dougherty		doughera@lafayette.edu