RE: Error: Can't load '/cygdrive/c/Oracle/Ora81/bin/Oracle' for module DBD::Oracle...
From: Lubomir G. Vassilev (lyubomir_at_ou.edu)
Date: Mon, 1 Nov 2004 10:33:42 -0600 To: "Andy Hassall" <firstname.lastname@example.org>, <email@example.com>
> -----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'
> module DBD::Oracle...
> > What do you mean by clean out?
> I mean unpacking DBD-Oracle-1.16.tar.gz from scratch and starting
> "make clean" gets rid of most stuff but starting again makes extra
> 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
> Hang on - isn't that the job of "make install"? How do you mean
> you're not unpacking the tarball to the Perl lib directories directly
> > then
> > I set ORACLE_HOME to c:\Oracle\Ora81 and did "perl makefile.pl -v"
> Don't you mean "perl Makefile.PL -v" ? You can probably get away with
> case-insensitivity since the underlying filesystem is
> but it's not good practice. Probably not relevant.
> > this is the result:
> > INC => q[-Ic:/Oracle/ora81/oci/include
> > -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
> So that looks pretty much equivalent now.
> > LIBS =>
> > 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
> you seem to be compiling from inside the Perl lib directories - is
> valid approach? It's not one I've come across before.
> > 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
> 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'
> ... which goes to standard error - looks like you've only posted
> Then again, even with this set, I still get a successful
> > 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
> > not mess with LD_LIBRARY_PATH at all. And I am still getting the
> > same error.
> Right, going back to your original posted outputs, you were getting
> whilst building:
> gcc -c -I/cygdrive/C/Oracle/Ora81/oci/include
> _USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include
> -O2 -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\"
> hread-multi-64int/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
> .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 -
> 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
> 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
> 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
> 1.16 I have, even after building with a Microsoft compiler, so where
> coming from on your system?
Ops, my bad, I lied earlier (unintentionally). The reason why it's
looking for "stdafx.h" is because I put it there. I was stupidly trying
to compile the whole thing in Visual Studio .NET and added that line
there. Anyway, I downloaded a fresh copy of DBD:Oracle from CPAN and I
am not getting this error now, but I am getting a whole bunch of new
- application/octet-stream attachment: make_output.log