This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Trouble building current CVS libc on RH9


On Thu, Oct 23, 2003 at 04:43:20PM -0700, sean@xenadyne.com wrote:
> 
> Hi,
> 
> I'm trying to build an October 22 CVS checkout of libc,
> because I want to do some tests on current NPTL, 
> and I'm having a few troubles.
> 
> First, I configure in a separate build directory:
> 
> $ pwd
> /home/sean/Glibc/Current/build
> $ ../libc/configure --with-tls --enable-add-ons=nptl --disable-profile --prefix=/home/sean/gnu 
> 
> 
> Problem 1: configure fails in libc/nptl/sysdeps/pthread/configure,
> due to "error: CFI directive support in assembler is required".
> I upgraded to binutils 2.13.92 and this did not currect the error.
> Is this actually an autoconf problem?

That binutils is still too old.  I think 2.14 will work.

> Problem 2: libc/libio build fails, because __EXCEPTIONS is not
> defined in libc/nptl/sysdeps/pthread/bits/stdio-lock.h. How does
> __EXCEPTIONS get defined, and why wouldn't it be defined here?

Then your GCC is still too old.  Try 3.3.1 or 3.3.2.

> Problem 3: building libc/sunrpc fails in an assertion in NPTL code:
> 
>    rpcgen: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork:
>    Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1)
>    asm volatile ("movb %%gs:%P2,%b0" : "=q" (__value) : "0" (0), "i"
>    (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value)
>    == 4) asm volatile ("movl %%gs:%P1,%0" : "=r" (__value) : "i"
>    (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value)
>    != 8) abort (); asm volatile ("movl %%gs:%P1,%%eax\n\t" "movl
>    %%gs:%P2,%%edx" : "=A" (__value) : "i" (((size_t) &((struct pthread
>    *)0)->tid)), "i" (((size_t) &((struct pthread *)0)->tid) + 4)); }
>    __value; }) != ppid' failed.
> 
> What does this failure indicate? Considering how complex the assertion is,
> it seems as likely that the assertion is faulty. Should I simply comment
> it out?

The assertion is valid.  This is a consequence of too old tools.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]