"configure: error: the compiler must support C cleanup handling"

Robert P. J. Day rpjday@mindspring.com
Sat Oct 29 16:29:00 GMT 2005

On Sat, 29 Oct 2005, Arno Schuring wrote:

> > p.s.  given that i'm still unclear on the various thread-related
> > configure options, i'm still looking for what to say to make sure
> > that the installation of the glibc headers installs "pthread.h"
> > along with everything else.
> Been following this thread only slightly, so sorry if this is no new
> info:
> FAFAIK, there are two hacks you can use to get pthread.h at the
> glibc install-headers step in crosstool. The easiest one is a manual
> copy of nptl/sysdeps/pthread/pthread.h into the target's include
> directory (the same thing crosstool does for stdio_lim.h). You might
> also try to configure glibc with --enable-add-ons=nptl instead of
> --disable-sanity-checks, but then you will run into the C cleanup
> mess you mentioned earlier. To circumvent (and this you will need
> for the next step too):
> $ echo "libc_cv_forced_unwind=yes" > config.cache $ echo
> "libc_cv_c_cleanup=yes" >> config.cache ${GLIBC_DIR}/configure
> [options] --cache-file=config.cache
> note: I haven't tried this second option, I have always opted for
> the copy alternative. I guess this should work though...

actually, i got past this with the "--with-tls" option for configuring
glibc and have now returned to the previously-discussed error when
building glibc:


../sysdeps/generic/strtok.c: In function 'strtok':
../sysdeps/generic/strtok.c:66: error: unable to find a register to
spill in class 'R0_REGS'
../sysdeps/generic/strtok.c:66: error: this is the insn:
(insn 68 107 69 5 (set (mem/c/i:SI (plus:SI (reg:SI 12 r12)
                (reg/f:SI 1 r1 [177])) [0 olds+0 S4 A32])
        (reg:SI 0 r0)) 171 {movsi_i} (insn_list:REG_DEP_TRUE 62
(insn_list:REG_DEP_TRUE 67 (nil)))
    (expr_list:REG_DEAD (reg:SI 0 r0)
        (expr_list:REG_DEAD (reg/f:SI 1 r1 [177])
../sysdeps/generic/strtok.c:66: internal compiler error: in
spill_failure, at reload1.c:1890


  so while it seems we went in circles ("sam ... we've been here
before."), i'm getting this while building an NPTL-only toolchain, so
that's *some* progress.


p.s.  the changes i made to get here have been incorporated into my
mini crosstool script.  i'm going to clean it up slightly and might
post it again so others can have a hack at it and suggest

Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

More information about the crossgcc mailing list