On Tue, Dec 03, 2002 at 05:16:27PM -0800, Josh Wilmes wrote: > Tim- > > Your suggestion did seem to do the trick. However, this is going to be > pretty painful for us to implement, as new new build of perl uses a > different architecture-specific directory (sun4-solaris-thread-multi vs. > sun4-solaris). > > Basically we'd have to recompile all of our installed modules, or we'd > have to hack perl to use the old architecture name
Probably wouldn't work anyway - they're not binary compatible - which is why they have different architecture names. > i'm not wild about either option, really. > > Is this our only choice at this point, or is there any way to work around > this in the DBD world? > > Do you know what's happening here? I presume that it's got something to > do with bringing in the threading headers at compile time- something is > overridden to a different implementation in non-threaded vs. threaded mode? I believe it's Solaris voodoo linker magic for thread support so a non-threaded application can dynamically load a threaded shared library. Normally works great, this is an unfortunate exception. Personally I'd suggest you go with loading DBD::Oracle explicitly before the DBI->connect call. If all your applications load some module of your own you could just put the "use DBD::Oracle;" into that. Or else hack your local DBI.pm to load it. Tim.
