Front page | perl.perl5.porters |
Postings from May 2007
Re: Perl in LSB 3.2
Thread Previous
|
Thread Next
From:
Andy Dougherty
Date:
May 17, 2007 11:31
Subject:
Re: Perl in LSB 3.2
Message ID:
Pine.LNX.4.62.0705171410210.17468@fractal.phys.lafayette.edu
On Thu, 17 May 2007, Vadim wrote:
> Andy Dougherty wrote:
>
> >On Thu, 17 May 2007, Vadim wrote:
> >
> >>Different configurations of same tarball will not be binary compatible,
> >>(threaded and unthreaded perls are binary not compatible, -Dusemymalloc,
> >>etc.)
> >True. The biggest issues (threads, 64-bit) are given distinct
> >architecture names, and so (by default) install in different directories,
> >and hence never collide. There are so many possible configurations,
> >however, that giving them all distinct names is out of the question.
> >Fortunately, you usually have to go out of your way to specify one of
> >those configurations, so this should not be a common problem. There may
> >well be a few more common permutations Configure should handle.
> >Suggestions are welcome.
> >
> I suggest for every shared lib to contain some checker function which
> just return a string of about ten characters to describe current binary,
> something like this:
>
> char *check_perl_config(char *) {
> return "5.8:00110"; // usemymalloc=0; threaded=0; multiplicity=1, etc
> }
I don't see any fundamental problem with that, though filling in the 'etc'
would take a lot of work. %Config has over a thousand entries.
Obviously all of them are not relevant, but there are stil a lot that
change binary compatibility.
> Exactly this approach will work for Windows but not for Linux, where you
> can't have functions with same name from different shared libs.
> >
> >>Dynaloader makes no attempts to recognize compatibility of Perl
> >>extensions, so resulting in Perl crashes.
> >True. However, it should normally be difficult to crash perl in this way
> >(unless you are a developer installing developer releases). Incompatible
> >versions of Perl extensions shouldn't normally get installed in the same
> >$Config{archlib}. Without knowing in more detail what sequence of events
> >you have in mind, I'm inclined to blame whatever tool is putting them
> >there instead of blaming DynaLoader. I have many incompatible
> >configurations all installed at once, and I don't recall ever having this
> >problem.
> >
>
> Actually I like blaming DynaLoader very much :) :) :)
> It paranoically checks $^O during runtime to check whether it suddenly
> moved to 'VMS'
Fair enough, though hardly relevant for this topic.
> I even started fixing it but then got no resources, so stopped doing this.
Alas, I know that problem all too well too.
> All in all, I think placing different DLLs (shared libraries) in
> predetermined directory is not enough. This way you're hardening doing
> moveable distributions, which are very desireable aspect of Perl.
I don't see why it makes it harder. You should still be able to move the
$Config{prefix} around as long as you keep the organization under that
prefix the same.
> >
> >>IMO the situation with pTHX/aTHX_ isn't perfect, and, once again, this
> >>situation on Win32 is slightly better (export names of functions with
> >>different configurations differ, so avoiding incorrect functions calls)
> >>
> >>
> >
> >A more basic question is: Why are incompatible configurations even
> >visible to each other at all? (This is assuming, of course, that you
> >don't go out of your way to make them visible.)
> >
> >
> >
> My real-life example is this.
>
> I use my favourite file manager and sometimes call predefined Perl
> scripts (for example copy current path to clipboard)
> But in some directories the script refuses to work, and it appears
> because some incompatible perl.dll happen to be in that directory, and
> Windors OS takes it from current directory, no matter that current
> directory is not in PATH.
I'm not familiar with perl on Windows, so I'm afraid I don't understand
what is happening here. What is 'perl.dll' and why is DynaLoader trying
to load it?
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next