[Date Prev][Date Next]
Re: compiling back-perl with perl 5.8.0
On Mon, 04 Nov 2002 14:44:54 -0500
"Kervin L. Pierre" <firstname.lastname@example.org> wrote:
> I can't remember the details right now, but how we build back-perl
> depends on how perl itself was built. The needed change is due to
> the change in the perl embed api between versions 5.6 and 5.6.1, I
> Currently, If perl is built with MULTIPLICITY ( which allows more
> than one interpreter to run ) then OpenLDAP could crash on the first
> use of the interpreter in a thread that did not create it. Thats
> because PERL_SET_CONTEXT macro has to be called with the interpreter
> The new MULTIPLICITY flag is where most of the change occurs, and to
> be more precise, some of the changes protected by HAVE_WIN32_ASPERL
> should be protected under HAVE_PERL_MULTIPLICITY which should be set
> at config time using 'perl -V' autoconf type test to figure out if
> it is needed.
Currently all threads seem to reference the same perl interpreter,
protected by a mutex.
So we the accessing-interpreter-from-the-wrong-thread problem can be
fixed by PERL_SET_CONTEXT wrapped in a test for multiplicity, yes?
Probably just inside the mutex.
I'm not clear about the limits of the multiplicity system; is it
possible to give each thread it's own instance of an interpreter?
Does a call to PERL_SET_CONTEXT affect other threads or interpreters,
or is it entirely thread-local, provided no other threads mess with
the interpreter(s) involved?
perlembed indicates building perl with -Dusethreads and -Duseithreads
may be more appropriate for this arrangement.
I'm somewhat confused about HAVE_WIN32_ASPERL... it looks like what
I'd expect from an autoconf system checking for options in perl -V,
but if I run find -type f |xargs grep ASPERL on the openldap tree, the
only usage of it seems to be the #ifdefs in
Was it part of the autoconf tests at one point, and should it be
> Do a 'perl -V' and check what defines perl was built with.
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
> The 'my_perl' errors are due to the new naming of the implicit perl
> interpreter variable, I believe. It use to be called something
> else. Another perl define that may need to be looked at is
/* pTHX is needed often now */
# define PERL_INTERPRETER my_perl
Looks like the backend wants to call the interpreter different things
for different versions. If we make the same changes for checking
MULTIPLICITY this should work fine.
> I'd be happy to help anyone who's interested in making the updates.
Thank you, I'll see what I can do.