Hi.  I haven't been active on this list for a while, so this may be
(probably is) a previously-asked question.  

MacOS X 10.2 comes with Perl 5.6.  MacOS X 10.3 (Panther) comes with
Perl 5.8.  I discovered a couple months ago that a pp-generated
executable for 10.2 won't run on 10.3 (then in beta).  I seem to
recall that the error message was that libperl.dylib doesn't exist, I
assumed because they renamed it (though why they then could not have
left both perls installed, I don't know).  I also remember reading
that numerous internal structures (including the C extension
interface) changed, so most modules with their own shared libraries
would have to be rebuilt.  The upshot, it seemed to me at the time,
was that a single pp-generated executable would not and could never
work with a system-provided libperl that might be 5.6 or 5.8.

Furthermore, I recall, it is not possible just to ship a 5.6 libperl
with my pp-generated executable, because the rest of MacOS X's shared
libraries have incompatible binary interfaces from 10.2 to 10.3 (which
is another way of saying that "MacOS X 10.2 and MacOS X 10.3 are
essentially different, incompatible operating systems").

With all that in mind, what is the best way to distribute a Perl-based
application on MacOS X?  I'm thinking the only solution is to ship a
.par file containing only my own Perl modules and code, all of which
must be pure Perl, and spawn the perl interpreter directly with the
.par file, trusting/using the local installation for all standad
libraries (I remember that PAR provides this option, I just don't
remember the details).  Or, of course, I could just ship my perl code
directly, but I prefer the marginal source-code hiding provided by
PAR.

Is this the correct solution for MacOS X?

Thanks,

Barry

Reply via email to