Cygwin + Oracle (Pro*C)

Peter A. Castro doctor@fruitbat.org
Sat Mar 15 09:06:00 GMT 2003


On Fri, 14 Mar 2003, günter strubinsky wrote:

>  günter strubinsky
>  <strubinsky@acm.org>
>  Tel: 402.212.0196
> 
> > -----Original Message-----
> > From: Peter A. Castro [mailto:doctor@fruitbat.org]
> > Sent: Friday, March 14, 2003 3:47 PM
> > To: günter strubinsky
> > Cc: cygwin@cygwin.com
> > Subject: RE: Cygwin + Oracle (Pro*C)
> > 
> > On Fri, 14 Mar 2003, günter strubinsky wrote:
> > 
> > > Well, it's not as trivial. The windows installation of Oracle
> > preconfigures
> > > for Visual C and creates all the micro$oft junk. There is no makefile as
> > > example.
> > 
> > This is only partially true.  While Oracle does provide a graphic
> > interface for many things, most of the command line environment is also
> > present, just like the unix ports.  lsnrctl is an example.  It's a
> > command line utility to manipulate the listener, just like in the unix
> > ports.  proc is another.  proc takes the same command lines as documented
> > in the Pro*C manual.  These manuals should be available online at
> > oracle.com, or on the Documentation CD which should have been shipped
> > with the installation CD.
> > 
> > > The documentation is virtually not existent, adapting to Microsoft's
> > way:
> > > 'The user is too stupid to understand; keep them in the dark so they
> > can't
> > > harm'. That's why there is a windows GUI-application that allows one
> > button
> > > precompile.
> > 
> > This is not true.  Windows is a more graphicly inclined environment, and
> > Oracle often tries to provide easy and simple tools appropriate for the
> > given environment.  Windows easily accommodates graphic interfaces and
> > customers often like to keep with one paradigm instead of having to
> > switch between two or more.  Many unix environments might be running
> > under X, but often they are just opening xterms to type commands.
> > 
> > > # I need to know how to invoke the precompiler manually.
> > 
> > Set your $PATH and go seek the manual.
> > 
> > > # How to compile & link the resulting C file.
> > 
> > This is not what your original email stated.  Compiling and linking is a
> > different, but arguably related, topic from "how to get proc to work
> > under cygwin".  Since proc is just a windows app, you can run it like any
> > other windows app from a cygwin shell.
> > 
> > > It is very hard to deduct what lib's and .h files should be included,
> > > especially since the directory tree is huge. I will dig around and make
> > it
> > > work. Sooner or later. Sooner would be naturally better.
> > >
> > > Therefore: if anybody got further than me. I appreciate any hints you
> > > provide and will post whatever conclusions I derive. Without HTML! 8p
> > 
> > Common headers are provided in the public directories of the various
> > products.  Most Oracle libraries under Windows are DLLs.  Check the demo
> > directories under precomp for some example code and makefiles.
> > 
> > I'm getting the impression you want to compile & link using gcc and not
> > Visual C++.  If that's the case, then this will likely not work, or at
> > least will take a large amount of effort.  Oracle uses the MSVCRT runtime
> > which has been proven to not mix well with cygwin and gcc runtimes.
> > A little more definition on your goals would really help here.
> > 
> 
> [gs] 
> I apologize if I wrote so fuzzy. I assumed that when I wrote 'running proc'
> everybody would imply that I don't want a resulting C program to look at but
> actually to run its compilage.

Well, you know the old saying about ASSuming, yes :)

Anyway, I know of many projects which pre-process stuff on one system,
then ship it to another system for actual usage.  I suggest that next
time you more fully state your needs.

> I guess, it's best to download the linux install and check some of their
> makefiles. My knowledge about CygWin is not sufficient enough to even guess
> how friendly it is with win2k libraries.

That's not necessary, really.  Cygwin is an emulation layer on top of
Windows, so it, necessarily, needs to be able to load/link with native
Windows link-libs and runtime.  This is because the underlying OS is
still Windows and Cygwin must work within that context.  Some common
Windows DLLs are kernel32.dll and user32.dll.  Microsoft's C-runtime
(MSVCRTxx.DLL) provides a mostly full set of standard C runtime
functions.  The problem is that GCC also provides a set of standard C
runtime functions.  The two tend to overlap (among other things) and
loading both is like having two people sit in the drivers seat of a car.
The both want to steer :(.  The solution is to pick one environment and
stick with it.  Now, there's a difference between using tools in one
environment and building something to be run in another environment.
This is typically called cross-compiler, but that's not quite what you
are trying to do. 

Now, your specific problem is that Oracle provides libraries built for
the MS environment, not the Cygwin environment.  So, you will have to
build your app using MS Visual C++.  This is completely separate from
running Pro*C, however!  Pro*C is only a *SQL* C-preprocessor.  It
translates embedded SQL into embedded OCI calls in source form.  You then
run that source file through a compiler and linker.  You can use Cygwin's
make facility to run each step (precompile, compile, link) using some
standard makefile target rules.  The samples provided by Oracle should
give you an idea of how to do this. 

Don't confuse using the tools for what the tools generate.  At work, I
use Cygwin's make to build product using the Visual C++ compiler & linker
and it all works just fine.  Note that I don't use the Visual C++ IDE GUI
at all (well, except for debugging, but that's not the same as using the
IDE to develope code).  You will have to be careful of include paths and
environmental variables, but that's manageable.

My suggestion to you, to even see if proc works for you, is to open a
bash shell, cd to the Oracle Home's bin/ directory and type "./proc" and
see if it runs.  If so, that's step one.  If it doesn't run, then either
proc isn't installed or some PATHs are wrong.  If it does run, then you
can pre-process your source.  Pro*C is self contained.  It doesn't need
any header files, it doesn't compile your code nor does it link it for
you.  You then have to compile it using Visual C++'s "cl" command and
eventually linking it with Visual C++'s "link" command. 

As I said, you should be able to find some "public/" directories in both
the RDBMS and PRECOMP directories under the Oracle Home.  If not, then
perhaps they weren't installed.

> About the dll's: 
> I found by coincidence a reference to dlltool. I deduct that CygWin CAN
> access dll's somehow (I am FUZZY again, this time out of ignorance). 

Yes, you can use dlltool or gcc directly to generate a .DLL and import
libs.  That's not the problem.  The problem is that the runtime you want
to use (Cygwin/gcc's?) won't work with the Oracle libraries.  This is the
fundamental problem. 

> I uninstalled sadly enough Visual Studio 6 and replaced it with VS7 aka.
> .Net. That was a bad idea and I don't have the vs6 cd's anymore. 

Pity, that.  .CRAP ... err, I mean ".NET" is not a very developer
friendly environment.  I'd get back to VC6 if at all possible. 

> BUT: the msvcrt<nn>.dll and the likes are kinda public domain and can be
> downloaded legally. I checked, they are here locally.

They aren't public domain at all.  If you have the Visual C++ developers
kit, then you are granted a re-distribution license for just those DLLs.
This is what Oracle does.  When you installed Oracle, it also installed a
version of the MSVCRT into your Windows System directory.  It used to be
installed in the ORACLE_HOME/bin directory but there were too many
problems with that (multiple versions of the same runtime don't play nice
together), so they are placed in a global place.

> I will try with the docs available and if I can't solve it until the end of
> the week, I'll tackle it with a different approach. I'll install RedHat and
> Oracle for RedHat and will either go through the pain trying to adapt CygWin
> or stick with RedHat. I would however have liked the original approach. It's
> such a pain to reboot...fro OS to OS :(

Keep in mind that pre-compiler on one platform and building on another is
doable, but compiling and/or linking on one platform and linking/running
on another won't work in this case.  You can't compile and/or link under
RedHat Linux and then expect to be able to link/run under Windows or
Cygwin.  I'd stay in one environment and simply get things to work.  Try
something simple, like make CL compile a simple "hello world" and making
it link.  If you can do that, then you can create a makefile to do it
next.  After that see if you can make proc run from the makefile.  After
that it's just a matter of getting the header file paths correct and
getting the link-lib list correct.

Well, anyway, Good luck with your project.

> günter
> 
> 
> > >  günter strubinsky
> > >  <strubinsky@acm.org>
> > >  Tel: 402.212.0196
> > >
> > > -----Original Message-----
> > > From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf
> > Of
> > > Peter A. Castro
> > > Sent: Thursday, March 13, 2003 6:36 PM
> > > To: günter strubinsky
> > > Cc: cygwin@cygwin.com
> > > Subject: Re: Cygwin + Oracle (Pro*C)
> > >
> > > On Thu, 13 Mar 2003, günter strubinsky wrote:
> > >
> > > > Does anybody have any experience running Oracle 9i (win2k) + cygwin
> > with
> > > > the pro*C preprocessor? Howto?
> > > >
> > > > I don’t have a glue how to get proc to work under cygwin. When I
> > install
> > > on
> > > > win2k I don’t think I can run the proC tool over the cygwin
> > environment?!?
> > > > Or can I install Oracle’s RedHat version?
> > >
> > > It should be pretty trivial.  Set your path to include $ORACLE_HOME/bin
> > > (that means you have to set ORACLE_HOME first, and it probably should be
> > > in DOS syntax).  ProC is just another windows command line app, so it
> > > should run on top of Cygwin without any problems.  Are you having a
> > > specific problem?
> > >
> > > > I am lost right now

> > > >  günter strubinsky
> > > >  < <mailto:strubinsky@acm.org> strubinsky@acm.org>
> > > >  Tel: 402.212.0196
> > >
> > >
> > 
> > --
> > Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
> > 	"Cats are just autistic Dogs" -- Dr. Tony Attwood
> 
> 

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list