Re: Q: Another oracle install fail. WHY!?!?!?!

From: Youri N. Podchosov <ynp_at_ynp.dialup.access.net>
Date: Sun, 11 Dec 1994 17:13:58 EST
Message-ID: <1994Dec11.171358_at_ynp.dialup.access.net>


In article <3cdoq0$t55_at_panix.com>, gsa_at_panix.com (Gary Assa) writes:
|>
|> As usual, and oracle installation failed. I have never been able to get
|> one to go on the first try? Doesn't Oracle corp test their installs before
|> they ship. this is really pissing me off!
|>
|> Why did I get this error?
|>
|>
|> >>> Relinking product executables
|> -----------------------------------------------------------------------
|> Relinking executables...
|> (make -f oraterm.mk ORACLE_HOME=/usr/oracle install)
|> -----------------------------------------------------------------------
|> rm -f oraterm
|> /bin/idld /usr/oracle/lib/ostart.o -L/usr/oracle/lib -o oraterm
|> /usr/oracle/lib/liboktc.a /usr/oracle/lib/libokt.a liboraterm.a
|> /usr/oracle/lib/liboktc.a /usr/oracle/lib/libokt.a liboraterm.a
|> /usr/oracle/lib/liboktc.a /usr/oracle/lib/libokt.a /usr/oracle/lib/libora.a
|> -lnlsrtl -lcv6 -lcore -lnlsrtl -lcv6 -lcore /usr/oracle/lib/libora.a
|> /usr/oracle/lib/olm.o /usr/oracle/lib/old.o /usr/oracle/lib/ols.o -lnsl_s
|> /usr/oracle/lib/olc.o
|> ld: Symbol tmpnam in /usr/oracle/lib/olc.o is multiply defined. First
|> defined
|> in liboraterm.a
|> *** Error code 1
|>
|> Stop.
|> >>> Relinking Error. The executables were not made successfully.
|> >>> Leaving oraterm.ins
|> -----------------------------------------------------------------------
|> ORAINST: Product installation finished on
|> Fri Dec 09 22:47:34 EST 1994 - uid=200(oracle) gid=100(dba)
|> -----------------------------------------------------------------------
|>
|>
|> How do I fix this, and I also noticed that my .profile was not altered to
|> add the needed environment variable to run oracle. Can someone please
|> e-mail me a sample .profile to run v7.1.3.0.0?
|>
|> Also, I run coraenv and I get an error. Shit, will an Oracle install ever
|> work?
|> --
|> ---------------------------------------------------
|> 1. Earth is 98% full. Please delete anyone you can.
|> 2. I came, I saw, I deleted all your files.
|> 3. The world will end in 5 minutes. Please log out.

I completely agree with what Gary sais about Oracle installations. You may not believe me, but the last installation that went *absolutely* OK I had when was putting Oracle V3.0 (sic!) on some IBM m/f Soviet-made clone with VM/370 (CMS). Then I went through V4.0 and 5.0 and 6.0.xx and 7.0.xx, and now I'm going to install 7.1.3.0.0 (versions 5 to 7 all were SCO variants).

It's unbelievable how poorly Oracle treats its installation procedures. The spectre of possible problems ranges from the necessity to [re]define working environment in some not obvious and - naturally - nowhere mentioned way (at best), to the complete "dead end" where you realize that distribution files/layout/media is/are hopelessly screwed up and there's nothing to do but to call Oracle for replacement of entire tape/CD/truck-with-disks (at worst).

I'm really sick and tired of that. Some four or fives months ago I managed somehow (I can't stop wondering at that up to now here) to finish with installation of 7.0.15 in less than 8 hours, and it was my first try with 7.0.xx. Indeed, there were some problems with mounting CD and doing rebuilds, but all in all - it worked. I was so astonished that posted in c.d.o a detailed description of what I did, which problems and inconsistencies encountered and what workarounds found. To my surprise, my post didn't get any responses or comments, from which I concluded that people are mostly pretty happy with what Oracle offers now for O7. Man was I wrong, at least *we* weren't happy at all, neither with another 7.0.15 nor with the next 7.0.16.

Now, I see Gary's post... What can I say? Theoretically, it's possible that due to some absolutely exotic SCO configuration at his site, make generates improper list of object modules in ld command line, in the sense that olc.o is *not* needed for this build (?), but I doubt it. Most possibly, the distribution just mixes modules from different sub-releases or branches or whatever structural units are supported by source/project control system used at Oracle Corp.: once the definition of tmpnam was in some code included in olc.o, but later it was moved to another file incorporated in liboraterm.a, or vice versa; then the old copy of one of those sources was included in Gary's distribution.

OK, almost for sure, I'm wrong with this scenario, this is just what could easily be imagined off the top of one's head, but how else can be this explained? I always thought that it's a very well known "feature" of SCO's linker (don't know about others): you can't link together object modules in which a function is defined as global (w/o static) more than once. So how comes this tmpnam is present both somewhere in liboraterm.a and olc.o? Did anybody at Oracle build oraterm from those components included in (this particular) distribution?

OK, well, too long and probably totally incoherent.

For Gary: send the tape or CD back and ask for replacement - don't having sources you won't be able to rebuild oraterm (what else?) unless - again - the list of linking components may be rearranged in a way preventing duplication of code for tmpnam.

For Oracle: you've got a *great* RDBMS, is Oracle Installer - just a make-like/curses-sugared utility with simple config script language - really the toughest part of Oracle? (Well, I admit it's not based on curses, but it doesn't matter for what I'm talking). Please do something, believe me, this sort of a buggy and unreliable installation procedure is simply unworthy of such a serious powerful multi-featured DBMS!

+-----------------------------------------------------------------------------+
| Youri N. Podchosov (ynp) *** Davidsohn & Son, Inc. NYC *** 718-234-4140 | | Internet: ynp_at_ynp.dialup.access.net CIS: 72723,2202 AOL: ynp, yourip |
+-----------------------------------------------------------------------------+
Received on Sun Dec 11 1994 - 23:13:58 CET

Original text of this message