Re: Pro*C and gnu C on SUN
Date: 23 Jan 93 04:21:48 GMT
Message-ID: <dtb.727762908_at_otto>
mahmoud_at_icts01.kodak.com (Ahmed Mahmoud) writes:
>We are planning on using gnu C with pro*c with oracle version 7 on a SUN 670
>running sunos 4.1.2. Does anybody out there have any idea why this should not
>work...has anyone out there tried this combination....has anyone used gnu with oracle???? thanks for any info on this matter....Ahmed Mahmoud
Re: Pro*C and GNU C on SunOS
The question about Pro*C and Gnu C is an interesting one, and also raises the issue of WHICH C compiler on the Sun to use of the two supplied as standard.
As background, remember that SunOS stems from the BSD world. SunOS 4.1 is also known as Solaris 1. Solaris 2 on the other hand is based on System V.4.
SunOS 4.1 comes standard with TWO C Compilers.
/bin/cc The BSD based compiler Gets default includes and libraries from /usr/include and /usr/lib /5bin/cc The AT&T compiler Gets default includes and libraries from /usr/5include and /usr/5lib
Oracle recommends that when using Pro*C (or even installing and linking Oracle) you have the /5bin directory ahead of /bin in your PATH variable.
This is good practice anyway, because you will get used to the Sys V versions of commands (df and ps are good examples of this - I usually create a soft link to /bin/ps and /bin/df as /usr/local/bin/bps and /usr/local/bin/bdf - a similar practice to HP when they supply both versions of a utility).
The BSD and AT&T compilers use libraries and include files from different directories, reflecting the system libraries of the two different dialects of UNIX. Sometimes the function is just called under another name, sometimes the number of parameters (and their ordering) is different.
GNU compilers and libraries are typically based on BSD.
Examples include
Get working directory getcwd vs. getwd Copy Memory memcpy vs bcopy Compare Memory memcmp vs bcmp
Obviously, if the Oracle libraries have references to the System V version, they will either be unresolved in the BSD libraries, or worse, resolve to something inappropriate.
You can get around this by one or more of the following
(1) Using GNU C, but point at System V libraries (2) Using GNU C and libraries but add in your own, written in GNU C that mimic the system V calls. You'll know which ones you need, as they will be the unresolved references. Some of these may simply be stubs that call the BSD function of a different name. (3) Stick to /5bin/cc (4) Extract the functions you need from the AT&T libraries and add them to your list to be linked in.
Look, I know it involves some hacking, but if you are that keen on Gnu C and only using your products in-house, you should be OK. I am not knocking Gnu C, mind you. Gnu C is a must for many shops developing in-house code and compiling things from the net. One R&D shop I worked in tried it out on our code, and it gave better quality executables than the native HP compiler at the time !!!! Nevertheless, we released commercial object and executables made from the HP product, using GNU for projects only to be used in house.
If anyone gets a problem of this nature because of an unresolved external and cannot figure out what it is for, drop me an e-line and I'll try and get back to you soon. However, I do spend time out of my office and offline and thus may take some time to get back to you.
David T. Bath Email:dtb_at_otto.bf.rmit.oz.au Phone:+61-3-3477511 Global Technology Corporation, 179 Grattan St, CARLTON, VIC, 3153, AUSTRALIA "Failure to emulate is the best revenge" - Marcus Aurelius
-- David T. Bath Email:dtb_at_otto.bf.rmit.oz.au Phone:+61-3-3477511 Global Technology Corporation, 179 Grattan St, CARLTON, VIC, 3153, AUSTRALIA "Failure to emulate is the best revenge" - Marcus AureliusReceived on Sat Jan 23 1993 - 05:21:48 CET