RE: Error: Can't load '/cygdrive/c/Oracle/Ora81/bin/Oracle' for module DBD::Oracle...
From: Andy Hassall (andy_at_andyh.co.uk)
To: "'Vassilev, Lubomir G.'" <email@example.com>, <firstname.lastname@example.org> Date: Mon, 1 Nov 2004 21:18:54 -0000
OK, the test failures in that output file you posted are probably because
you haven't set ORACLE_USERID and/or issues with your Oracle name resolution
configuration, but it's built and at least appears to load under your
configuration. Set the ORACLE_USERID environment variable to a valid Oracle
login so that the tests can run... it's important to run the tests to
validate that the module has built correctly, and it requires access to an
Oracle database to do so.
[ Going off-topic for dbi-users - for further information I'd recommend the
comp.lang.perl.misc newsgroup on Usenet - accessible through
groups.google.com if you haven't got access to a proper NNTP server. ]
The main thing to remember here is DON'T unpack distributions into the Perl
library directories yourself. It's "make install"'s responsibility to copy
the files into the right places - and _only_ when it's all built correctly.
Unpack it somewhere entirely different - e.g. your home directory. I tend
to make a 'src' directory for compiling in my home directory. For example,
the following changes to your home directory, creates a directory, and then
you can start downloading source and compiling from there:
You've now messed up your Perl library directories somewhat, having
unpacked the source code into the library directories. If you haven't
customised your Cygwin installation too much, I'd be strongly inclined to
wipe it out and reinstall Cygwin, then install the modules the proper way -
You should probably at least delete:
You should get away with this so long as you haven't tried to install any
other modules this way.
Far more convenient is using the CPAN module: type 'cpan' at your shell to
get an interactive interface to this. Installing a new module becomes as
simple as "install modulename". The module takes care of setting up
temporary directories to build in, and will download the latest version,
unpack, compile, download and build any dependencies (this is particularly
useful!), test and, if all the previous steps succeed (or you specify
'force' if you are _sure_ you can accept any test failures) install the
library into the Perl library directories.
Once again: you should (almost) never modify anything in the Perl library
directories yourself - the module's "make install" handles that.
More information at these URLs:
(Cygwin is more Unix than Windows so the Unix instructions apply -
I've only skimmed this page, but it seems basically reasonable)
-- Andy Hassall <email@example.com> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> > -----Original Message----- > From: Vassilev, Lubomir G. [mailto:firstname.lastname@example.org] > Sent: 01 November 2004 17:06 > To: Andy Hassall; email@example.com > Subject: RE: Error: Can't load > '/cygdrive/c/Oracle/Ora81/bin/Oracle' for module DBD::Oracle... > > Alright! It looks like it's working now. Here is what I did. I got a > fresh copy of DBD:Oracle from CPAN an unpacked in > c:\cygwin\lib\perl5\site_perl\5.8.5\cygwin-thread-multi-64int\ DBD. Then > I went to that directory and build and tested. Here is the result: > > > -----Original Message----- > > From: Andy Hassall [mailto:firstname.lastname@example.org] > > Sent: Friday, October 29, 2004 3:53 PM > > To: Vassilev, Lubomir G.; email@example.com > > Subject: RE: Error: Can't load '/cygdrive/c/Oracle/Ora81/bin/Oracle' > for > > module DBD::Oracle... > > > > > What do you mean by clean out? > > > > I mean unpacking DBD-Oracle-1.16.tar.gz from scratch and starting > again - > > "make clean" gets rid of most stuff but starting again makes extra > sure > > when > > things get confusing. > > > > > I placed a fresh copy of DBD::Oracle in > > > c:\cygwin\lib\perl5\site_perl\5.8.5\cygwin-thread-multi-64int\DBD > and > > > > Hang on - isn't that the job of "make install"? How do you mean > "place" - > > you're not unpacking the tarball to the Perl lib > directories directly > are > > you? > > > > > then > > > I set ORACLE_HOME to c:\Oracle\Ora81 and did "perl makefile.pl -v" > and > > > > Don't you mean "perl Makefile.PL -v" ? You can probably > get away with > > case-insensitivity since the underlying filesystem is > case-insensitive... > > but it's not good practice. Probably not relevant. > > > > > this is the result: > > > > > [snip] > > > INC => q[-Ic:/Oracle/ora81/oci/include > -Ic:/Oracle/ora81/rdbms/demo > > > -I/usr/lib > > > /perl5/site_perl/5.8.5/cygwin-thread-multi-64int/auto/DBI/] > > > > My INC was: > > > > INC => q[-Ig:/oracle/ora81/oci/include > -Ig:/oracle/ora81/rdbms/demo > > > -I/usr/lib/perl5/site_perl/5.8.5/cygwin-thread-multi-64int/auto/DBI/] > > > > So that looks pretty much equivalent now. > > > > > LIBS => > > > > [q[-L/cygdrive/c/cygwin/lib/perl5/site_perl/5.8.5/cygwin-thread-multi- > > > 64int/DBD -loci]] > > > > My LIBS was: > > > > LIBS => [q[-L/home/andyh/src/DBD-Oracle-trunk -loci]] > > > > So the difference here is I'm compiling from a copy in my home > directory > > - > > you seem to be compiling from inside the Perl lib directories - is > that a > > valid approach? It's not one I've come across before. > > > > [snip] > > > LD_RUN_PATH=c:/Oracle/ora81/lib:c:/Oracle/ora81/rdbms/lib > > > > This doesn't look valid - LD_RUN_PATH is colon-separated > (since it's > a > > Cygwin and hence Unix-like variable) - so the colons in the drive > > specifications will cause problems here. > > > > If I set a similar LD_RUN_PATH, I get the following output: > > > > Ignoring LD_RUN_PATH='g:/oracle/ora81/lib:g:/oracle/ora81/rdbms/lib' > in > > environment > > > > ... which goes to standard error - looks like you've only posted > standard > > output? > > Then again, even with this set, I still get a successful > > build/test/install. > > > > > Notice that INC is now set to the right path, i.e. no > cygdrive this > > > time, but LIBS is not. The only variable I set was ORACLE_HOME. I > did > > > not mess with LD_LIBRARY_PATH at all. And I am still getting the > exact > > > same error. > > > > Right, going back to your original posted outputs, you were getting > this > > whilst building: > > > > gcc -c -I/cygdrive/C/Oracle/Ora81/oci/include > > -I/cygdrive/C/Oracle/Ora81/rdbms/ > > demo > -I/usr/lib/perl5/site_perl/5.8.5/cygwin-thread-multi-64int/auto/DBI/ > > -DPERL > > _USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include > > -DUSEIMPORTLIB > > -O2 -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\" > > "-I/usr/lib/perl5/5.8.5/cygwin-t > > hread-multi-64int/CORE" -Wall -Wno-comment -DUTF8_SUPPORT > > -DORA_OCI_VERSION=\"8 > > .1.0\" dbdimp.c > > dbdimp.c:19:20: stdafx.h: No such file or directory > > dbdimp.c: In function `ora_db_login6': > > dbdimp.c:283: warning: unused variable `o' > > dbdimp.c:284: warning: unused variable `l' > > dbdimp.c:315: warning: cast to pointer from integer of > different size > > dbdimp.c:329: warning: cast to pointer from integer of > different size > > dbdimp.c:339: warning: cast to pointer from integer of > different size > > dbdimp.c:343: warning: cast to pointer from integer of > different size > > dbdimp.c:386: warning: unused variable `rsize' > > dbdimp.c: In function `dbd_rebind_ph_char': > > dbdimp.c:1121: warning: cast from pointer to integer of > different size > > make: *** [dbdimp.o] Error 1 > > > > The error in your subject is when you try and load DBD::Oracle - > since > > it's > > not built, it won't install, so failing to load the library isn't > > surprising. The root of the problem appears to be the error > above. Can > you > > confirm you still get THAT same error now? > > > > What's particularly suspicious is the reference to "stdafx.h". > > > > (a) That's a Microsoft compiler precompiled header file. You're > supposed > > to > > be using gcc, not the Microsoft compiler, so why is that appearing? > > > > (b) There's no reference to stdafx.h anywhere in the copy of > DBD::Oracle > > 1.16 I have, even after building with a Microsoft compiler, so where > is it > > coming from on your system? > > > > -- > > Andy Hassall <firstname.lastname@example.org> / Space: disk usage analysis tool > > <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> > > > > >