Every checksetup.pl run yields a pop-up on Windows with ActiveState Perl 5.10.0, saying "This application has failed to start because OCI.dll was not found. Re-installing the application may fix this problem." Workaround is to simply click Ok. This happens even without any intention to install Oracle -- I never installed DBD-Oracle, I think it came in with the ActiveState Perl install (ppm tells me the module is in "perl", not in "site"). I'm aware this can probably be cured by deinstalling DBD-Oracle. I still think we should do something about it because it'll probably bite *lots* of people after our next release.
IMO, this is not a Bugzilla bug. I fixed the problem by typing (from memory): ppm --remove --area perl DBD::Oracle This problem should be reported to ActiveState, who installs it by default with no reason. IMO, this bug is INVALID (not a Bugzilla bug).
Flags: blocking3.4? → blocking3.4-
It would require extensive amounts of workaround code just to fix this, which is (I agree with LpSolit) a bug in the package that ActiveState ships for DBD::Oracle. FWIW, it already affects people, our next release won't make any difference.
I've reported this bug to ActiveState: http://bugs.activestate.com/show_bug.cgi?id=82183
Shouldn't we implement either of the workarounds suggested in the ActiveState bug report? Namely either 1) use CPAN.pm to determine the version number of installed modules, or 2) call SetErrorMode() to disable Windows error dialogs. There's even working code for the latter case in the ActiveState bug report. And former seems something checksetup.pl should probably always do if that's somehow "better" method to determine versions or fixes some other symptoms of module loading we might have had to workaround in the past. Or is there a known reason neither of those can be used in Bugzilla?
Yeah, we could do the SetErrorMode thing.
Severity: normal → major
Priority: -- → P1
Hardware: x86 → All
BTW, the reason that we don't want to use CPAN.pm to determine versions is that we want checksetup.pl to do *exactly* what Bugzilla is going to do when loading the module, so that we know that it will in fact load and work and that all its prerequisites are installed--not just that it itself is on the filesystem somewhere.
This is the workaround recommended by ActiveState.
Assignee: installation → mkanat
Status: NEW → ASSIGNED
Comment on attachment 420620 [details] [diff] [review] v1 I can't test this, since apparently my installation doesn't have DBD-Oracle and I can't install it via PPM, but I do know that this compiles, and it's basically identical to the code from ActiveState.
(In reply to comment #8) > (From update of attachment 420620 [details] [diff] [review]) > I can't test this, since apparently my installation doesn't have DBD-Oracle and > I can't install it via PPM I have the same problem. Once it's removed, it seems impossible to reinstall it.
Comment on attachment 420620 [details] [diff] [review] v1 Hmmm. Byron, do you want to help us out with our dilemma here? :-)
Attachment #420620 - Flags: review?(LpSolit) → review?(bugzilla)
Comment on attachment 420620 [details] [diff] [review] v1 This resolves the problem for me.
Attachment #420620 - Flags: review+
Comment on attachment 420620 [details] [diff] [review] v1 Awesome; that's good enough for me.
Attachment #420620 - Flags: review?(bugzilla)
3.4 requires a different patch because it doesn't have init_console().
Attachment #420748 - Flags: review?(wurblzap)
Comment on attachment 420748 [details] [diff] [review] v1 (3.4) Yup, this works for me.
Attachment #420748 - Flags: review?(wurblzap) → review+
tip: Checking in Bugzilla/Install/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Util.pm,v <-- Util.pm new revision: 1.26; previous revision: 1.25 done 3.4: Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.561.2.1; previous revision: 1.561 done Checking in Bugzilla/Install/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Util.pm,v <-- Util.pm new revision: 188.8.131.52; previous revision: 184.108.40.206 done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.