On Tue, Dec 03, 2002 at 06:56:37PM -0800, Josh Wilmes wrote:
>
> After figuring that libthread was somehow to blame, we did a little
> fiddling around and found that DBD::Oracle is linking against -lthread,
> but the oracle libraries are _not_.
>
> We tried removing this library from the linking in the Makefile, and it
> appears to have done the trick!
>
> After doing "perl -p -i -e 's/-lthread//g' Makefile" and rebuilding, the
> test script executes properly on a non-threaded perl.
>
> I didn't try to understand why the Makefile included -lthread in the first
> place, but it certainly doesn't seem to be necessary on this platform.
[Sigh] DBD::Oracle included -lthread only because Oracle's own
makefiles told it to :(
> So far, this hack looks like it solves my problem. I've got my fingers
> crossed :)
Great.
Tim.
> --Josh
>
> At 17:16 on 12/03/2002 PST, Josh Wilmes <[EMAIL PROTECTED]> 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- 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.
> > >
> >
>
>
>
