PATCH Finding gas
Thu Sep 3 02:07:00 GMT 1998
Eric Schweitz wrote:
> When building egcs 1.0.3a on HP-UX 10 and using --with-gnu-as in the
> ./configure line, the executable produced still looks for the assembler
> in /usr/ccs/bin. I hacked the config/pa/hp*10.h where MD_EXEC_PREFIX
> was defined to remove this little annoying "mis-feature". Seems like
> this may be a "bug" in the configure script...
I too am having the same problem on sparc-solaris-2.5.1. My situation is
a little different though. I do not have root, and the normal gnu tools
have been installed in /usr/local/gnu/... (gas, ld, gcc, g++). I build
and install egcs into my local directory /home/staff/nathan/solaris/...
This way I can use egcs without hassling my friendly sysadmin (except
for asking for more disk!).
naturally my path is /home/staff/nathan/solaris/.. /usr/local/gnu/...
/usr/ccs/bin, so I get my tools overriding the gnu tools, which in turn
override the system tools.
I configure with --with-gnu-as --with-gnu-ld. (+ the prefix and
This doesn't work, the system assembler and linker are used.
/usr/ccs/bin ends up in the gcc binary. There appear to be two problems,
one of which I can fix (patch appended), the other has me confused in a
maze of twisty header files & configure scripts.
The patched problem is with gcc/configure.in when it works out the
capabilities of the assembler. The script tries to see if gas is in the
same build tree by attempting to examing ../gas. Unfortunately it
assumes srcdir is in the form `*/gcc', replacing the `gcc' with `gas'.
If srcdir is not set, it ends up as `.', the sed command fails leaving
the script looking for a `configure.in' in the current directory (which
of course succeeds). This configure.in naturally doesn't specify the gas
capabilites and so P2ALIGN and the like are not assumed. The patch
changes the sed to strip a trailing `/gcc' _if_ it's there, and then
always append a `/gas'. Therefore in my case the test for gas's
configure.in fails and the default as is used (/usr/local/gnu/bin/as in
I configure in the top level directory (parent of gcc directory), but
that configure script doesn't seem to export srcdir to the
subdirectories. I would have expected gcc/configure.in to have a srcdir
of the form */gcc passed to it. why isn't it? (I am familiar with
autoconf, but the gnu configure stuff is different isn't it?)
Now the second problem, is that even though configure has now found the
gnu assembler, it doesn't save the full path. The path to the assembler
(and linker) is constructed by using MD_EXEC_PREFIX, which for solaris
comes out of config/svr4.h (via config/sparc/svr4.h), and is
/usr/ccs/bin. I can't see a way of overriding this. passing LD=... and
AS=... environment variables into configure doesn't work.
Anybody got any clues about this? Should I hack configure to check for
$LD and $AS, use them and force their full paths into the binary?
Oh, yes, this is the 1.1 release (which I'm about to let free on other
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
You can up the bandwidth, but you can't up the speed of light
firstname.lastname@example.org http://www.cs.bris.ac.uk/~nathan/ email@example.com
More information about the Gcc-patches