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- 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?
--Josh
At 9:49 on 11/27/2002 GMT, Tim Bunce <[EMAIL PROTECTED]> wrote:
> Got a moment to gve this more thought...
>
> > ----
> > #!/usr/SD/perl/bin/perl
> >
> > #use DBD::Oracle;
> > use DBI;
> >
> > $SIG{ALRM} = sub { print "Caught alarm\n"; };
> >
> > alarm (2);
> > $dbh = DBI->connect('dbi:Oracle:eman', 'eman', 'eman');
> > alarm (0);
> >
> > sleep(5);
> > print "Success\n";
> >
> > ----
> > If the "use DBD::Oracle" line is uncommented, the script succeeds. If
> > commented out, it fails, and the $SIG{ALRM} handler doesn't work either-
> > it just prints "Alarm Clock" and exits.
> >
> > It appears that the oracle libraries are monkeying with the signal
> > handlers?
>
> May actually be Solaris when it dynamically loads a library that
> uses threading into an application that wasn't linked for threading.
>
> > I'm not really happy with the "use DBD::Oracle" workaround at this point-
> > i'd hate to miss some script somewhere while trying to add it.
> >
> > If there's a way to fix this in DBD, i'd prefer that, certainly.
>
> Try reconfiguring (and rebuilding) perl to support threads. Don't
> actually _use_ the threads support, but the fact it's there (ie
> perl was linked with -lthread) may be enough to avoid the problem.
>
> Please let us know if it helps.
>
> Tim.
>
