glibc-2.6 compile problem - Linux

This is a discussion on glibc-2.6 compile problem - Linux ; Can anyone look at this error log created by bash's stderr? I am having alot of trouble compiling glibc-2.6 I am using gcc-346 and glibc-23. Bill...

+ Reply to Thread
Results 1 to 11 of 11

Thread: glibc-2.6 compile problem

  1. glibc-2.6 compile problem

    Can anyone look at this error log created by bash's stderr? I am having
    alot of trouble compiling glibc-2.6 I am using gcc-346 and glibc-23.

    Bill





  2. Re: glibc-2.6 compile problem

    "Bill Cunningham" writes:

    > Can anyone look at this error log created by bash's stderr? I am having
    > alot of trouble compiling glibc-2.6 I am using gcc-346 and glibc-23.


    Have you tried with gcc 4.1 or 4.2?

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: glibc-2.6 compile problem


    > Have you tried with gcc 4.1 or 4.2?
    >

    No I haven't.

    Bill



  4. Re: glibc-2.6 compile problem

    "Bill Cunningham" writes:
    > Can anyone look at this error log created by bash's stderr? I am having
    > alot of trouble compiling glibc-2.6 I am using gcc-346 and glibc-23.


    The one message which isn't noise is

    pthread_mutex_timedlock.c: In function `pthread_mutex_timedlock':
    pthread_mutex_timedlock.c:276: error: `__NR_clock_gettime' undeclared (first use in this function)
    pthread_mutex_timedlock.c:276: error: (Each undeclared identifier is reported only once
    pthread_mutex_timedlock.c:276: error: for each function it appears in.)
    make[2]: *** [/glibc-2.6/f/nptl/pthread_mutex_timedlock.o] Error 1

    The 'most important' line is the second: __NR_clock_gettime should
    expand to the system call number associated with the clock_gettime
    system call. This is a macro which should normally be defined in
    /usr/include/asm/unistd.h, (asm-i486 or asm_x86_64 for "PCs"). This
    means that either

    - your kernel supports the system call, but a header not
    defining it 'for some reason' is (possibly erronously)
    included

    - your kernel doesn't support this system call

    The corresponding part from my unistd.h header is

    #define __NR_timer_create 259
    #define __NR_timer_settime (__NR_timer_create+1)
    #define __NR_timer_gettime (__NR_timer_create+2)
    #define __NR_timer_getoverrun (__NR_timer_create+3)
    #define __NR_timer_delete (__NR_timer_create+4)
    #define __NR_clock_settime (__NR_timer_create+5)
    #define __NR_clock_gettime (__NR_timer_create+6)
    #define __NR_clock_getres (__NR_timer_create+7)
    #define __NR_clock_nanosleep (__NR_timer_create+8)

    for a quick test if your kernel supports the call, you could just add
    these definitions to the file which cannot be compiled.



  5. Re: glibc-2.6 compile problem

    Thanks much I will look at unist.h. I know the header is there and it's
    version 2.4.36 of the kernel. I don't know if the kernel version needs
    changed or what.

    Bill



  6. Re: glibc-2.6 compile problem

    "Bill Cunningham" writes:
    > Thanks much I will look at unist.h. I know the header is there and it's
    > version 2.4.36 of the kernel. I don't know if the kernel version needs
    > changed or what.


    2.4.36 has (AFAIK) no POSIX.4 support. If that's the kernel you are
    actually using, clock_gettime cannot be used.

  7. Re: glibc-2.6 compile problem


    "Rainer Weikusat" wrote in message
    news:87fxtd95js.fsf@fever.mssgmbh.com...
    > "Bill Cunningham" writes:
    >> Thanks much I will look at unist.h. I know the header is there and
    >> it's
    >> version 2.4.36 of the kernel. I don't know if the kernel version needs
    >> changed or what.

    >
    > 2.4.36 has (AFAIK) no POSIX.4 support. If that's the kernel you are
    > actually using, clock_gettime cannot be used.


    Ok I must then be mixing something that's giving me an error. 2.4.36
    headers with a 2.4.35 kernel. I will have to compile a 2.4.36 kernel then I
    guess try again.

    Bill



  8. Re: glibc-2.6 compile problem


    > 2.4.36 has (AFAIK) no POSIX.4 support. If that's the kernel you are
    > actually using, clock_gettime cannot be used.


    I tried again with a 2.4.36 kernel image and 2.4.36 kernel headers and
    got the same problem. I don't know what kernel version to use with glibc-2.6
    the way it sounds in the docs this should work.

    Bill



  9. Re: glibc-2.6 compile problem

    > 2.4.36 has (AFAIK) no POSIX.4 support. If that's the kernel you are
    > actually using, clock_gettime cannot be used.


    After reading more docs it looks like I might have to move to a 2.6
    kernel. pthreads may not work on 2.4 kernels.

    Bill



  10. Re: glibc-2.6 compile problem

    "Bill Cunningham" writes:
    >> 2.4.36 has (AFAIK) no POSIX.4 support. If that's the kernel you are
    >> actually using, clock_gettime cannot be used.

    >
    > After reading more docs it looks like I might have to move to a 2.6
    > kernel. pthreads may not work on 2.4 kernels.


    There are two different pthreads-implementations for glibc/ Linux:

    - The old/ traditional one named LinuxThreads. While it has a
    couple of shortcomings wrt POSIX support, most notably, no
    concept of per-process signals and no concept of a 'process
    id' separate from the id of a particular kernel task (each
    of which corresponds with a thread), it will work with 2.4
    and 2.6 (and older kernels, fwiw)

    - The (not so) new one, named NPTL (Native POSIX Thread
    Library), which addresses the issues I mentioned above (and
    a few others, eg faster thread creation on multiprocessors
    and more lightweight sleep/ wakeup mechanism), but will work
    only with 2.6-kernels.

    I am using NPTL on 2.6, running on (small) multicore-PCs for 'server
    tasks', and LinuxThreads on 2.4.35/ ARM926 and they both work
    satisfactorily.

  11. Re: glibc-2.6 compile problem

    [snip]

    > - The (not so) new one, named NPTL (Native POSIX Thread
    > Library), which addresses the issues I mentioned above (and
    > a few others, eg faster thread creation on multiprocessors
    > and more lightweight sleep/ wakeup mechanism), but will work
    > only with 2.6-kernels.
    >
    > I am using NPTL on 2.6, running on (small) multicore-PCs for 'server
    > tasks', and LinuxThreads on 2.4.35/ ARM926 and they both work
    > satisfactorily.


    That's were the compile breaks. There's an error concerning NPTL.

    Bill



+ Reply to Thread