Mail Archives: cygwin/2003/03/15/15:33:36
In http://www.cygwin.com/ml/cygwin/1997-09/msg00085.html Chris got a pro*c
program to work. I will send him email. As halflife for IT jobs is right
now, the chances to find him/her at the company email address is doubtful
since the email is from last millennium (1997). Sadly s/he was not very
specific.
I found all the lib's and I guess the linker works 'the usual way'. As soon
as the first entry in the library path has been found it will be included in
the obj. and the search for this one module is considered done!?! Or is the
linker a multipass one who would warn me that there are more than modules
with the same name in different libs? In this case the order would be vital,
deciding over life or dead of the program.
It's been a couple of days, when I did VS6. I think to recall that you can
either fully qualify the dll you want to access or the dynamic loader checks
along the search path. What I don't know (but logic suggests the following )
is what happened if I call a dll function which already exists in one LOADED
dll. I guess, if it's not fully qualified the dynloader won't even bother
(performance) to look for other locations along the path if it finds the
entry in one of the already loaded dll's.
What happens if one entry exists in two dll's, both loaded is far over my
head. Does the dynloader check within the dlls in the (temporal) order in
which they have been loaded fifo like or uses a chain and looks backward
(assuming that the last loaded dll is the most likely candidate) = lifo
wise. Or does the OS/loader generate a hash table and the results are
unpredictable (I doubt that, because it would in this case detect that there
are same name/different source entries). Dll's advantage over libs is that
they are loaded once in a global memory/address space and can be accessed
from any program/thread on the system. Woahh! That complicates things a bit,
doesn't it? Generation conflicts should be the norm, not the exception. And
since MS's own code is generally not backwards compatible to itself there
must be a conflict resolution mechanism (which until win2k solved the
conflict into the famous blue screen :( ).
So, I love peer input!!!!!
Does my above rambling make sense to you?
Could it be that if I put the cygwin dll's last in the path, the
msvcrt* would kick in first?
Would this also mean that the system itself gets totally unpredictable
since cygwin wants its own implementation but gets spoon-fed with the M$
one?
What order should I use for the static libs?
----------------------------------------------------------------------------
----------
Last not least, it's time to put an end to the 'charset' discussion about my
first HTML email I sent. You purists should be quiet. Using smaller and
smaller charsets is oldfashioned. We live in the third millenium. The good
ol' times are over where you shaved the head of your slaves, tatooed the
message on their head, let the hair grow back and sent them their merry way
to transport secret messages. IPSEC is the answer. Incompatible Standards
another (instant messaging into Nirwana e.g.). Since the Net (without dot)
is the modern way of informations transport and everybody knows that, there
is a lot of traffic going on. All the spam that needs to be delivered, the
'get rich from your living room', the 'lonely housewives' and 'watch
Pay-Per-View for free while you get rich from your living room while you
meet the lonely housewives' ads. That takes bandwidth. Sure you could limit
the characters so that we use only 7 bits per byte and günter becomes
guenter, semicolon becomes ',.' a.s.o. and you could save all the bits and
live off the interest, but it's the wrong approach:
You ever heard of 'a picture says more than 1000 words'?
Ever programmed in APL?
My solution is as simple as elegant: Let's use pictographs like the
Egyptians did 5k years ago or more currently the Chinese do. Each Symbol is
one word!!!
Another advantage: The average page contains only 5 percent dark dots. And
95% white ones. What a waste of white dots! If you use a compact
characterset as chinese AND colorize the characters changing their meaning
(let's say with 65535 different colors) you can probably put this whole
message in 12 or 13 characters! Those compact characters have less white
dots, would be more efficient. Right? Now that is progress!!! Don't look
backwards! Btw. That would also rid the market from all those wasteful COBOL
programmers ('ADD this TO that GIVING itall.') who would not survive the new
compactness. We could send 1000 times more 'stuff envelopes' emails and
Carnivore would work more efficient too. Looking for the 'red bomb'
character or the 'black plague' symbol, etc.
The singer 'Prince' started the revolution already with his own name as a
pictograph. Let's finish it!
Got my point?
günter strubinsky
<strubinsky AT acm DOT org>
Tel: 402.212.0196
> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf
> Of Peter A. Castro
> Sent: Friday, March 14, 2003 7:47 PM
> To: günter strubinsky
> Cc: cygwin AT cygwin DOT com
> Subject: RE: Cygwin + Oracle (Pro*C)
>
> On Fri, 14 Mar 2003, günter strubinsky wrote:
>
> > günter strubinsky
> > <strubinsky AT acm DOT org>
> > Tel: 402.212.0196
> >
> > > -----Original Message-----
> > > From: Peter A. Castro [mailto:doctor AT fruitbat DOT org]
> > > Sent: Friday, March 14, 2003 3:47 PM
> > > To: günter strubinsky
> > > Cc: cygwin AT cygwin DOT 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 AT acm DOT org>
> > > > Tel: 402.212.0196
> > > >
> > > > -----Original Message-----
> > > > From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On
> Behalf
> > > Of
> > > > Peter A. Castro
> > > > Sent: Thursday, March 13, 2003 6:36 PM
> > > > To: günter strubinsky
> > > > Cc: cygwin AT cygwin DOT 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 AT acm DOT org> strubinsky AT acm DOT org>
> > > > > Tel: 402.212.0196
> > > >
> > > >
> > >
> > > --
> > > Peter A. Castro <doctor AT fruitbat DOT org> or <Peter DOT Castro AT oracle DOT com>
> > > "Cats are just autistic Dogs" -- Dr. Tony Attwood
> >
> >
>
> --
> Peter A. Castro <doctor AT fruitbat DOT org> or <Peter DOT Castro AT oracle DOT 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/
--
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/
- Raw text -