intermittent gcc bug with /usr/ccs/bin/as

intermittent gcc bug with /usr/ccs/bin/as

[Edward Peschko]

hey all,

I've got a very frustrating bug with gcc 3.4.3 on solaris 5.8 - I'm hesitant even 
to put it in the bug database because it is IS so intermittant - but it is basically 
mucking up all of my compiles because it happens everywhere, but is not reproducible.

Basically, some times gcc ignores the fact that a gnu 'as' is in my path, 
and opts to use /usr/ccs/bin/as instead.  In fact, /usr/ccs/bin is nowhere in my 
path, ld_run_path or ld_library_path - nowhere in my environment, really. 
The system will compile normally, and then run up against /usr/ccs/bin/as
errors.

But the next time I compile, the error is nowhere to be seen.


So - what's going on here? I'm assuming its a 3.4.3 bug because 3.2.3 wasn't 
affected by it... And what do people need in order to track it down and fix it? 
It's most annoying..

Ed

btw - here's an example, compiling gq-1.4.3:


----

LD_LIBRARY_PATH      => /opt/tools/generic/dev/2.8/lib:/opt/tools/generic/dev/2.8/lib:/opt/tools/install/lib:/opt/oracle/920/lib32:/usr/openwin/lib:/usr/dt/lib:/opt/IBMdb2/V6.1/lib
LD_RUN_PATH          => /opt/tools/generic/dev/2.8/lib

CXX                  => /opt/tools/generic/dev/2.8/bin/g++
CC                   => /opt/tools/generic/dev/2.8/bin/gcc
LDFLAGS              =>  -L/opt/tools/generic/dev/2.8//lib -R/opt/tools/generic/dev/2.8//lib
CONFIG_SHELL         => /opt/tools/generic/dev/2.8/bin/bash
CFLAGS               => -g -O3

tools@linux> /opt/tools/generic/dev/2.8/bin/bash ./configure --prefix=/opt/tools/generic/dev/2.8/ 

tools@linux> /opt/tools/generic/dev/2.8/bin/make CC="/opt/tools/generic/dev/2.8/bin/gcc" CXX="/opt/tools/generic/dev/2.8/bin/g++"

---
if /opt/tools/generic/dev/2.8/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I -I.. -I.. -DLOCALEDIR=\""/opt/tools/generic/dev/2.8//share/locale"\" -I/opt/tools/generic/dev/2.8//include -I/opt/tools/generic/dev/2.8//include/gtk-2.0 -I/opt/tools/generic/dev/2.8//lib/gtk-2.0/include -I/opt/tools/generic/dev/2.8//include/atk-1.0 -I/opt/tools/generic/dev/2.8//include/pango-1.0 -I/opt/tools/generic/dev/2.8//include -I/opt/tools/generic/dev/2.8//include/freetype2 -I/usr/openwin/include -I/opt/tools/generic/dev/2.8//include/glib-2.0 -I/opt/tools/generic/dev/2.8//lib/glib-2.0/include    -I/opt/tools/generic/dev/2.8//include  -g -O3 -MT thumb.o -MD -MP -MF ".deps/thumb.Tpo" \
  -c -o thumb.o `test -f 'thumb.c' || echo './'`thumb.c; \
then mv -f ".deps/thumb.Tpo" ".deps/thumb.Po"; \
else rm -f ".deps/thumb.Tpo"; exit 1; \
fi
if /opt/tools/generic/dev/2.8/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I -I.. -I.. -DLOCALEDIR=\""/opt/tools/generic/dev/2.8//share/locale"\" -I/opt/tools/generic/dev/2.8//include -I/opt/tools/generic/dev/2.8//include/gtk-2.0 -I/opt/tools/generic/dev/2.8//lib/gtk-2.0/include -I/opt/tools/generic/dev/2.8//include/atk-1.0 -I/opt/tools/generic/dev/2.8//include/pango-1.0 -I/opt/tools/generic/dev/2.8//include -I/opt/tools/generic/dev/2.8//include/freetype2 -I/usr/openwin/include -I/opt/tools/generic/dev/2.8//include/glib-2.0 -I/opt/tools/generic/dev/2.8//lib/glib-2.0/include    -I/opt/tools/generic/dev/2.8//include  -g -O3 -MT utilops.o -MD -MP -MF ".deps/utilops.Tpo" \
  -c -o utilops.o `test -f 'utilops.c' || echo './'`utilops.c; \
then mv -f ".deps/utilops.Tpo" ".deps/utilops.Po"; \
else rm -f ".deps/utilops.Tpo"; exit 1; \
fi
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 16: error: quoted-string operand required
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 16: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 17: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 17: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 22: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 22: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 26: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 26: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 30: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 30: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 34: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 34: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 38: error: unknown opcode ".loc"
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 38: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccHQQzk4.s", line 50: error: unknown opcode ".loc"
....
etc. 
....
---

Re: intermittent gcc bug with /usr/ccs/bin/as

[Geoffrey Keating]

Edward Peschko <esp5@pge.com> writes:

> Basically, some times gcc ignores the fact that a gnu 'as' is in my path, 
> and opts to use /usr/ccs/bin/as instead.  In fact, /usr/ccs/bin is nowhere in my 
> path, ld_run_path or ld_library_path - nowhere in my environment, really. 
> The system will compile normally, and then run up against /usr/ccs/bin/as
> errors.
> 
> But the next time I compile, the error is nowhere to be seen.

That's odd.  The compiler should use /usr/ccs/bin/as all the time,
irregardless of PATH, on Solaris, unless you've overridden it at
configure time.  Is it possible that /usr/ccs/bin/as is, say, on a
soft-mounted NFS disk, and so the compiler can't find it sometimes?

Re: intermittent gcc bug with /usr/ccs/bin/as

[Joe Buck]

On Thu, Dec 09, 2004 at 02:47:25PM -0800, Edward Peschko wrote:
> Basically, some times gcc ignores the fact that a gnu 'as' is in my path, 
> and opts to use /usr/ccs/bin/as instead.

Perhaps you're running Solaris, and you didn't specify "--with-gnu-as",
or an explicit assembler, when you built gcc?

gcc does not use your path to find the assembler (or, rather, it uses the
path only if it fails to find an assembler in standard places).  It has
its own concept of the path to be used to search for compiler passes.

To force the use of a particular assembler, you can make a symbolic link
from the directory where the compiler passes (cc1, cc1plus, etc) are
stored, to the assembler you want, with the name "as".  This location is
always searched first.  With 3.4.x this directory is

$prefix/libexec/gcc/$system/$version

where $prefix is the --prefix specified when you ran configure, $system
is the target triplet, e.g. "sparc-sun-solaris2.9", "i686-pc-linux-gnu",
etc., and $version is the version, e.g. "3.4.3".

Re: intermittent gcc bug with /usr/ccs/bin/as

[Edward Peschko]

On Thu, Dec 09, 2004 at 03:39:11PM -0800, Mike Stump wrote:
> On Thursday, December 9, 2004, at 02:47  PM, Edward Peschko wrote:
> >I've got a very frustrating bug with gcc 3.4.3 on solaris 5.8 - I'm 
> >hesitant even
> >to put it in the bug database because it is IS so intermittant
> 
> I'll assume that you built the compiler correctly...  if not, 
> rebuild/reinstall...
> 
> The compiler and binutils should have the same prefix, and the 
> compiler, when built, should use the --with-gnu-as=bla option, or 
> however it is spelled.
> 
> The compiler usually isn't intermittent, so this would tend to indicate 
> a problem in your automounter, your filesystem...  try a local 
> filesystem...
> 
> Run a trace with strace/ktrace/trace and see what the system calls that 
> try and open ../as do and what they return.  If you put in a shell 
> script into the same directory that has cc1 called as, and have it exec 
> /bla/bla/as "$@", I thinking it should never escape back to 
> /usr/ccs/bin.

ok... I figured out what it was (it was me being too smart for my own good).
A long convoluted story, but even though /usr/ccs and gcc were locally 
available, the gnu 'as' was not available for small periods of time, 
and it looks like gcc runs back to /usr/ccs/bin/as by default.


Although, one could argue that - if you compile with --with-gnu-as=...
you should get a *fatal error* if that gnu as is not available, not
an attempt to use sun's version...

Ed