binutils-2.14: gmake check fails on Solaris9.

[Hugh Sasse Staff Elec Eng]

On Fri, 12 Mar 2004, Nick Clifton wrote:

> Hi Hugh,
>
> > So I was thinking there might be something to filter the core file
> > in order to yield information to better effect that my efforts above.
>
> You could try running the link process under gdb, so that when it does
> seg fault GDB will catch it.  That often works for me.

I thought the ld was being invoked (silently) by gcc, so I'd never
find the command line?
>
> Another very useful thing, since this appears to be a memory
> corruption problem, would be to turn on malloc() debugging.  I am not
> familiar with Solaris9 so I do not know if it has this feature, but
> under Linux you can set a magic environment variable to have the
> loader choose a debugging malloc shared library instead of the normal
> one.

Interesting: I'm trying to build this with gnu ld and gcc, so I
should have access to that feature while avoiding the sun tools,
shouldn't I?  Or should I poke around for electric fence and ...
wotsit? It's something I've read about but not used, so can't do
that off the top of my head.
>
>
> > So now with binutils from cvs what happens?  Errr, nothing: it
> > builds but won't install from cvs:
> >
> > gmake[2]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/src/bfd/po'
> > gmake[2]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/src/bfd'
> > gmake[3]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/src/bfd'
> > gmake[3]: Nothing to be done for `install-exec-am'.
> > /bin/sh ./../mkinstalldirs /scratch/local/lib
> > /bin/sh ./../mkinstalldirs /scratch/local/include
> > /bin/sh ./libtool  --mode=install ./install-sh -c libbfd.la /scratch/local/lib/libbfd.la
> > ./install-sh -c .libs/libbfd.lai /scratch/local/lib/libbfd.la
> > ./libtool: ./install-sh: not found
>
> Well that's a bummer.  Is the install-sh script is in the top level
> directory not the bfd directory, so it ought to be looking for
> ../install-sh.  I have no idea what went wrong with the configure
> process to make it make this kind of mistake however.

There are a LOT of *.log files, many config.log in various dirs.  I
retried this and tried to do a make check again today, so thus found
them while looking for diags. So many to look at I didn't explore
find . -type f -name "*.log" -exec grep install.sh {} \; -print
which would be likely to produce spadefuls of eclectic rubbish :-)?

>
> Cheers
>         Nick
>
        Thank you,
        Hugh