/usr/ccs/bin/as errors in Solaris 10
underh20
errors when upgrading the Oracle to 11G-R2. Any idea how I could
resolve this issue ? Thanks, Bill
INFO: /usr/ccs/bin/as
INFO: : error: unknown option '6'
/usr/ccs/bin/as: error: unknown option '4'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF] [-xarch=
{v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b}] [-xcode={pic13,pic32}]
file.s...
INFO: make: Fatal error: Command failed for target `ntcontab.o'
INFO: *** Error code 1
Chris Ridd
The problem is in whatever's calling 'as' with the wrong arguments
(perhaps "-64"?), not in 'as'. Has 'cc' been changed in any way, eg
does $PATH contain another one, or have symlinks been put in which
alter it?
--
Chris
David Kirkby
wrote:
It's a GNUism.
Someone has built some code which assumes your gcc is configured to
use the GNU assembler, when in fact your gcc is configured to use the
Sun assembler.
When gcc is built, the person that builds it can chose to have gcc use
the Sun assembler or GNU assembler, by using the configure option --
with-as.
On a SPARC, the gcc supplied by Sun uses the Sun assembler.
kirkby@t2:[~] $ /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/
gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --
without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-
languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
(Note the --with-as=/usr/ccs/bin/as)
On my Sun Ultra 27, Sun supplied gcc configured to use the GNU
assembler.
bash-3.2$ gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-111a/usr/src/cmd/gcc/gcc-3.4.3/
configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --
with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c+
+,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)
For most programs, you do not need to worry too much over this, as the
compiler will sort out the options to send to the assembler. But if
you go out of your way, you can force an option on the assembler using
the -Wa option to gcc. (A similar option, -Wl will send something
directly to the linker). Once you start sending things directly to the
linker or assembler, then you need to know what linker and assembler
the compiler uses. It would appear in your case that someone has
assumed you are using a gcc built to use the GNU assembler, when in
fact yours uses the Sun assembler. I can produce that error very
easily.
kirkby@t2:[~] $ gcc -Wa,-64 exp.c
/usr/ccs/bin/as: error: unknown option '6'
/usr/ccs/bin/as: error: unknown option '4'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch=
{v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
kirkby@t2:[~] $
In contrast, the -64 option is a valid option to the GNU assembler.
I'd report it to whoever wrote the software. Let the f***ing idiots
know that not everyone uses GNU tools. The Sun linker, especially on
SPARC has a better reputation than the GNU one.
But the easiest way out of your problem is to either try to find
another gcc on the system which is configured to use the GNU
assembler. If not:
1) Build GNU binutils, which will include the assembler 'as'
2) Build gcc, using the option --with-as=/path/to/GNU/as
Dave
David Kirkby
>
> It's a GNUism.
> Dave
Here's another example of this sort of problem. In this case, someone
has tried to pass the option -W directly to the assembler, using -Wa,-
W The -W option is used to suppress warnings from the GNU assembler.
But it backfires when the Sun assembler is used.
g++ -O2 -g -Wa,-W -fno-exceptions -Wno-deprecated -DINCLUDE_PARI \
-I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include/pari -
I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include\
-I ../include/ -L/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/
lib \
cmdline.c \
Lcommandline.cc Lcommandline_elliptic.cc Lcommandline_globals.cc
\
Lcommandline_misc.cc Lcommandline_numbertheory.cc \
Lcommandline_twist.cc Lcommandline_values_zeros.cc \
Lgamma.cc Lglobals.cc Lmisc.cc Lriemannsiegel.cc \
-o lcalc -lpari -lmpfr -lgmpxx -lgmp -liberty
/usr/ccs/bin/as: error: unknown option 'W'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch=
{v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
/usr/ccs/bin/as: error: unknown option 'W'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch=
{v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
In a case like this, it was easy to fix just removing their compiler
option -Wa,-W. But in your case, it is probably safer to see if there
is a gcc on the system which uses the GNU assembler, or if not build
gcc to use the GNU assembler.
I wish I had a pound for every time I see a bit of code which GNU isms
in it. I'd be very rich!
Dave
underh20
Thanks for the information.
Unfortunately, i don't have any control of the 11G upgrade script form
Oracle.
So the script seems to be pointing to the wrong assembler "as". In our
case,
it's pointing at the Sun assembler and not the GNU assembler,
correct ?
There are "gcc" in /usr/local/bin and /usr/sfw/bin". Looks like it's
grabbing the incorrect gcc in /usr/local/bin.
Should we be using the gcc in "/usr/sfw/bin" exclusively for the
Oracle 11G upgrade script ?
On the other hand, how can we force to go to GNU assembler anytime
when
we issue the command /usr/ccs/bin/as ? Does the version of Solaris
10, e.g., 01/06
cause any issue here in the /usr/ccs/bin/as assembler useage ?
Thanks, Bill
atlantis> which gcc
/usr/local/bin/gcc
atlantis> ls -lt /usr/local/bin/gcc
-rwxr-xr-x 1 root other 187348 Sep 6 2000 /usr/local/bin/
gcc
atlantis> ls -lt /usr/sfw/bin/gcc
-r-xr-xr-x 3 root bin 122260 Jan 22 2005 /usr/sfw/bin/gcc
atlantis> /usr/local/bin/gcc -v
Using builtin specs.
gcc version 2.8.1
atlantis> /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/
gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --
with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-
languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
David Kirkby
> Dave,
>
> Thanks for the information.
>
> Unfortunately, i don't have any control of the 11G upgrade script form
> Oracle.
>
> So the script seems to be pointing to the wrong assembler "as". In our
> case,
> it's pointing at the Sun assembler and not the GNU assembler,
> correct ?
> There are "gcc" in /usr/local/bin and /usr/sfw/bin". Looks like it's
> grabbing the incorrect gcc in /usr/local/bin.
Oracle goes not know need to know where the assembler is. It will
invoke compiler. The compiler will then invoke the assembler. If gcc
is built to use one assembler, you should not change the assembler.
gcc can't grab the wrong assembler, unless you go out your way to
screw things up. If it is build to use the assembler in /usr/local/
bin, it will use that, even if /usr/local/bin is not in your path. The
path to the assembler is hard-coded in gcc.
I think you need to build gcc and add the appropiate option for it to
use the GNU assembler.
Paul Floyd
<underh20.s...@gmail.com> wrote:
>
> atlantis> /usr/local/bin/gcc -v
> Using builtin specs.
> gcc version 2.8.1
That's really old. Not much use for any C++, and probably not too
reliable for C either. If I were you, I'd uninstall or delete it.
> gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
GCC 3 is also rather old, but you can probably live with that one.
I'd also expect Oracle to work with Sun Studio, which generally produces
better optimized code.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr