Yeah, I did setup the ORACLE_USERID variable and the tests ran through successfully. I ran a small Perl script to connect to my Oracle db and it worked fine. However, I did unpack the DBD:Oracle directly in my Perl lib directory, i.e. I did not follow your advice. But as long as it works, I don't really care. In my defense though, I tried unpacking in my home dir first and do "make install" but that didn't work because that directory name contained white spaces.
I am not really concerned with the quality of my Perl module installations because I am only using Perl, and CygWin for that matter, to run Ora2Pg to convert an existing db from Oracle to PostgreSQL. After that I might even remove it from my machine. > -----Original Message----- > From: Andy Hassall [mailto:[EMAIL PROTECTED] > Sent: Monday, November 01, 2004 3:19 PM > To: Vassilev, Lubomir G.; [EMAIL PROTECTED] > Subject: RE: Error: Can't load '/cygdrive/c/Oracle/Ora81/bin/Oracle' for > module DBD::Oracle... > > 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: > > cd > mkdir src > cd src > > 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 > - > see below. > > You should probably at least delete: > > > /cygdrive/c/cygwin/lib/perl5/site_perl/5.8.5/cygwin-thread-multi- > 64int/DBD/D > BD-Oracle-1.16 > > 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: > > http://search.cpan.org/~andk/CPAN-1.76/lib/CPAN.pm > > http://www.cpan.org/modules/INSTALL.html > (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 PROTECTED]> / Space: disk usage analysis tool > <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> > > > -----Original Message----- > > From: Vassilev, Lubomir G. [mailto:[EMAIL PROTECTED] > > Sent: 01 November 2004 17:06 > > To: Andy Hassall; [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > > Sent: Friday, October 29, 2004 3:53 PM > > > To: Vassilev, Lubomir G.; [EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> / Space: disk usage analysis tool > > > <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> > > > > > > > > > >
