Well, time to re-install DBD::Oracle. It turns out perl 5.8.6 on this bsd box was built with threading support turned off, and then it turns out that the current DBD::Oracle seems to want threads turned on. We tried installing DBD::Oracle using the existing perl, but when we ran it, it crashed with a message about how the "Oracle.so" library file contains a reference to a "pthread_kill" symbol, which is undefined at runtime. (That's probably why the build log included this little gem of wisdom: "Warning: If you have problems you may need to rebuild perl with threading enabled.")
Okay, while we're at it, why not move ahead to 5.8.7, which is the common version at the moment for all our other bsd machines. But this would be the only one with threading enabled. (At least, until we decide that all the other machines should make the same change.)
And we're talking about our the web server. I would assume that every non-core module with compiled code needs to be resinstalled, which in itself is no problem, but what are the chances of some random module turning freakish, just because we now have threads enabled? (Obviously, none of our scripts are using threads at this point.)
At the very least, I'm looking for guidance on how best to approach this transition. The way it looks to me now, I'm thinking:
- build 5.8.7 with thread support but don't install it
- use the CPAN autobundle from the current 5.8.6 to fill in
the non-core modules, including DBI
- do our best to install DBD::Oracle on 5.8.7, even though
this perl isn't fully "installed" the way that the
DBD::Oracle readme says it should be
- try a bunch of existing apps, including DBI access to oracle8,
and assuming they work, do "make install" for 5.8.7
Of course, until that all pans out (or as long as it doesn't), DBI to oracle8 is broken on this machine. (Luckily, it's not in the "critical path".) All suggestions and warnings are welcome.
If I'm reading the error message correctly, you don't need to build a Perl with useithreads in order to fix your compile problem. Assuming I found the right one, the error message your referring to is:
print "WARNING: Oracle is built with multi-threading libraries\n"
. " You will most likely need to rebuild perl from sources\n"
. " with the following libraries: -lcl -lpthread\n" ;
Adding those options won't build a threaded Perl, it just builds it with threadsafe C runtime libraries and the pthread liraries. The resulting Perl will still be non-threaded, and not suffer the performance hit that imposes.
In any case, if you chose to build a threaded Perl, if DBD::Oracle uses (p)threads under the covers, there is no conflict between that can ithreads. The cloning of Perl data done for spawned iThreads , is a purely Perl affair and will not happen if non-perl library spawns threads--even if that library is dynalinked to a threaded perl.
Finally, going purely on what I see in the XS and C files for DBD::Oracle, it appears to be iThreads-aware, even if it's not warrented as iThreads-safe.
In summary, just add the options abive to the link command and (re)build your Perl as you would normally and your problems will (or should) just "go away", with no other risks or special considerations.
Perl 5.8.8 built on this box with gcc. DBI and Oracle::DBD also built and installed on this box. Previously 5.8.6 also working.
Sorry that this doesn't actually answer your questions but it does show that the setup does work.
The problem we did have is using 64bit Oracle and libraries. Most code puts 32bit in lib and 64bit in lib64. Oracle puts 64bit in lib and 32bit in lib32. You just need to make sure that when building you get the right versions.