as,nm,ar segfaulting while building libgcc

Phil Edwards pedwards@disaster.jaj.com
Thu Oct 12 12:30:00 GMT 2000


I'm using current CVS binutils+gcc in a unified tree.  (Yah, Mr. Bleeding
Edge am I...)  Doing a build of gcc on sparc-sun-solaris2.8 causes a number
of coredumps, all from the freshly-built binutils, all SEGVs:

    -rw-------   1 pedwards sysadmin  105020 Oct 12 15:17 core.ar.376
    -rw-------   1 pedwards sysadmin  391740 Oct 12 15:00 core.as-new.17649
    -rw-------   1 pedwards sysadmin  375356 Oct 12 15:00 core.as-new.17883
    -rw-------   1 pedwards sysadmin  358972 Oct 12 15:09 core.as-new.26647
    -rw-------   1 pedwards sysadmin  358972 Oct 12 15:09 core.as-new.26649
    -rw-------   1 pedwards sysadmin  367164 Oct 12 15:09 core.as-new.26651
    -rw-------   1 pedwards sysadmin  358972 Oct 12 15:09 core.as-new.26653
    -rw-------   1 pedwards sysadmin  358972 Oct 12 15:09 core.as-new.26655
    -rw-------   1 pedwards sysadmin  105020 Oct 12 14:56 core.nm-new.16586
    -rw-------   1 pedwards sysadmin  105020 Oct 12 14:56 core.nm-new.16588

Dunno why ar gets built as 'ar' instead of 'ar-new'.

Since the build only dies once, I suspect that maybe some of those
happened during configure tests.  There are config.log's scattered all
over the build dir, but I'll try to grep through those later.  The build
gets as far as gluing together libgcc.a:

    /tec/build/3test/binutils/ar  rc ./libgcc.a libgcc/./_muldi3.o
    libgcc/./_divdi3.o libgcc/./_moddi3.o
[...boatloads of .o's, we all know what they look like...]
    libgcc/./__main.o libgcc/./_exit.o libgcc/./_ctors.o libgcc/./_eh.o
    libgcc/./frame-dwarf2.o
    gmake[2]: *** [libgcc.a] Segmentation Fault (core dumped)
    gmake[2]: Leaving directory `/tec/build/3test/gcc'
    gmake[1]: *** [libgcc.a] Error 2
    gmake[1]: Leaving directory `/tec/build/3test/gcc'
    gmake: *** [all-gcc] Error 2

Worked just fine a couple days ago.

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


More information about the Binutils mailing list