I think that in the absence of an extensive test that showed the contrary, you have to assume that compiled XS modules must be compiled seperately for threaded and non-threaded use.

From the top of the threads module

Having threads support requires all of Perl and all of the XS modules 
+in
the Perl installation to be rebuilt, it is not just a question of addi
+ng
the threads module.  (In other words, threaded and non-threaded Perls
are binary incompatible.)
[download]

That seems pretty definitive. I would think that any case where you could get away with the same binary for both should be classified as "more luck that judgement":)

I'd test, but I cannot build perl-5.8.x on win32 without threads (nobody seems to be smoking that config on win32) which reminds me we need more smoke testers for windows. Grab Test::Smoke and go wild. We can always use more smoke testers.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

After Compline,
Zaxo

What I ended up doing was passing PREFIX=~/perl to the initial config program and also to CPAN. This has lead to a completely separate install for the threaded perl.

As a convenience I have linked /usr/local/bin/tperl to /home/evdb/perl/bin/perl so that it is easy in scripts to change the perl version that is used.

Pity that DBI doesn't trust itself with threads, it rather removed the point of having them for me, I'll go the trusty forking route instead....

Oh, I was running 5.8.0, 5.6.1 indeed!

--tidiness is the memory loss of environmental mnemonics

** Note that threads are only stable at Perl 5.8.0+. Don't compile old versions to use it.

Graciliano M. P.
"The creativity is the expression of the liberty".