Very Computer

>Here are some things to keep in mind:

>1) Make a user oracle7 before installing.  Give the user a >home dir where
>you want to install the system.

>2) export ORACLE_HOME = [oracle7's home dir] before starting. > The sysem has
>some trouble figuring this out for itself.  
>3) At the beginning of the install, the script ran df piped >thru sed to find
>out some disk space availabilities.  It somehow forgot that >the first line
>outputted by df has column headings, and therefore it was >trying to compare
>the *word* available (instead of the number beneath it on the >second line) to
>250000 or something like that.  I moved my df to df.real and >made a script
>which just echo'ed a bogus line from df that said I had tons >of space.  I
>wasn't into debugging their scripts!!!
>4) A note about replacing the binaries with scripts (like df >in #3).  You must
>have the "#! /bin/sh" thing at the top of the script or it >won't run.
>5) Create a directories /var/opt/oracle and /usr/lbin before >starting.  I don't
>know what permissions (I used 777!!!) because at the very end >of the install
>it will bomb if you don't have 'em.  Very annoying.
>6) When you get the "can't execvp" message, just type the >command it couldn't
>exec and you will be ok.
>7) The most difficult part of this is getting the compiler >tools for SCO (or
>imitating them with the COFF-development tools that are in the >same place as
>iBCS) to work.  They are *usually* called id** and here's a >list of what I
>made:
>/lib/idcomp -> /bin/idcomp
>/lib/idcpp -> /usr/bin/cpp
>/bin/idar -> /usr/i486-sysv4/bin/ar  (from the coff dev. >tools)
>/bin/idas -> /usr/i486-sysv4/bin/as-coff (from the coff >dev.tools)
>/bin/idcomp  (a shell script - see below)
>/bin/idcpp -> /usr/bin/cpp
>/bin/idld -> /usr/i486-sysv4/bin/ld (from the coff dev. tools)
>8)  There is a reason why idcomp is not simply a link to gcc. > After realizing
>that I would need idas to compile a coff .o file, I set out to >make a .s
>(assembly file) that it could handle.  My first attempts were >completely
>fruitless.  It wouldn't even handle the .s files that gcc >produced.  I
>tried uploading the .c file to a different machine with an >older gcc and
>compiling, and that would assemble, but it was compiled for a >SPARC processor
>so the definition of a WORD vs a LONG were different.  In >addition, gcc
>placed underscores before the symbols in a way that oracle >wasn't expecting
>and the objects weren't found in the libraries.  Eventually, I >realized that
>if I gave gcc the -b i486-linuxaout flag, it would make .s >files usable by
>as-coff.  I also made a perl script to strip out extra >underscores to make
>the symbols correct.  So....  Here's my idcomp script:
>----------------------------------------------
>#! /bin/sh

>gcc -b i486-linuxaout -S -o mytemp.s $2
>no_under.pl > $4

>----------------------------------------------
>And here's the perl script, no_under.pl:
>----------------------------------------------
>#! /usr/bin/perl

>open(MYTMP,"mytemp.s");

>while (<MYTMP>) {


>  $word =~ s/^_//;
>  print $word, " ";
>  }
>  print "\n";
>}
>----------------------------------------------
>Believe it or not, idcomp and idas will produce a coff .o file >with the
>correct symbols (assuming it's executable :-).
>You may want to test this on a .c file of your own.  Run >"file" against the
>resulting .o file, and you should see some nice results.  By >the way,
>idcomp expects to be called with parameters a la oracle >install scripts, which
> means the file to compile is the second parameter and the >output file is the
>fourth parameter.
>I think this is all, but if you run into problems, drop me a >line.
>David Mansfield