Front page | perl.perl5.porters |
Postings from August 2011
On Thu, May 17, 2007 at 08:16:02PM +0400, Vadim wrote: > Nicholas Clark wrote: > > >On Thu, May 17, 2007 at 07:54:26PM +0400, Vadim wrote: > > > > > >>Andy Dougherty wrote: > >>We can blame user on incorrect placing of DLL, but this will not improve > >>the actual situation :) > >> > >> > > > >Well, if Windows will insist that PATH has . in it... > > > >I guess, yes, on Windows we're going to have to compensate for this. > > > > > >But this isn't a *Linux* standards base issue. Does it effect any OS other > >than Win32? > > > > > > This incorrect behaviour could be generalized - shared library should be > recognized as wrong and rejected by application level, despite of OS > functionality. Yes, this seems like a thing we should do. Embed the "architecture" name in a shared libperl, and in the the main() routine, and bail out with a helpful message if the two disagree. Do we actually need a function to do this, or is it portable simply to define a global static string, and compare it with a local static string in "main()" (by "global static string" I mean the same mechanism as the other global static strings) > But if you're insisting that relocatable Perl is wrong (or impossible) > approach on Linux - so be it, I have no objections at all! No, sorry, I wasn't clear. I'm not. Relocatable perl is most definately do-able. Windows was ahead of the game here - the mechanism is only just in for *nix. But the default configuration on *nix is to have the perl executable contain the Perl C library routines (so that the executable around 1M). The alternative, having a shared Perl library (typically named libperl.so) with those routines, and a What we (this list) wasn't sure was easy to do was to solve chicken-and-egg problem - > >Also, on Windows, do shared library names have to fit in 8.3? > > > > > > shared names can be quite long. > > Best regards, > Vadim. > >Thread Previous | Thread Next