Skip to contentSkip to conversation

glibc update]

[email protected]: Carlos O'Donell Jr. 4 participants 5 messages Oct 18, 2001 – Oct 19, 2001

lore
Share & tools
lore
#0 lore raw

R,

Quoted 4 lines

1. the glibc i uploaded is actually built with a fairly old binutils (version 2.11.90.0.7-2.0.1). There could well be many binutils bug fixes since then, but at least for this case it lets us build glibc without the segfaults we see with the newer binutils

I'll see about giving it a try on my 712/60 and 715/50's

Quoted 5 lines

2. the newest binutils (2.11.92.0.5-3), also in incoming, doesn't appear to address the glibc build issue as i originally thought. we still get ld.so segfaults as Carlos has observed earlier. Perhaps someone (Carlos, Alan, Rob?) can look at the binutils changes since then can see what broke?

Eventually I'll get that assembly trace done.

Quoted 4 lines

3. with the glibc build (using old binutils) some of the linuxthreads tests are failing. in particular there's one case where it seems to get into a deadlock. i left it running overnight and it's still stuck ... i don't know if this has always been broken though.

This reminds me, in general I keep forgetting to add the location of /xxx/glibc-2.2.4/hppa-linux/obj to LD_LIBRARY_PATH. This nips some of the tests in the bud since ld goes looking for the wrong library.

Quoted 3 lines

Build logs for #3 and #2 above can be found at:
#3: http://people.debian.org/~tausq/glibc.build.log2
#2: http://people.debian.org/~tausq/glibc.build.log5

Have you tried running the tests by hand and seeing what the output is?

What is the output of running:
/home/randolph/gcc-3.0/glibc-2.2.4/hppa-linux/obj/math/test-fenv.out

c.

#1 lore raw
Quoted 6 lines
Quoted 2 lines

#3: http://people.debian.org/~tausq/glibc.build.log2
#2: http://people.debian.org/~tausq/glibc.build.log5

Have you tried running the tests by hand and seeing what the output is? What is the output of running:
/home/randolph/gcc-3.0/glibc-2.2.4/hppa-linux/obj/math/test-fenv.out

eh? that's the output report file :)

i get a floating point exception when running the corresponding executable.

Program received signal SIGFPE, Arithmetic exception. 0x4011b328 in vfprintf () from /lib/libc.so.6 (gdb) bt

#0  0x4011b328 in vfprintf () from /lib/libc.so.6
#1  0x40123490 in printf () from /lib/libc.so.6
#2  0x00010f8c in feenv_mask_test (
    flag_name=0x40210048 "@\036\177P@\036\177T@\036\177`@\036\177X@\036\177h@\036\177\220@\036\177�@\036\177�@\036\177�@\036\177�@\036\177�@\036\177�@\036\177�@\036\200", fe_exc=1) at test-fenv.c:332
#3  0x0001160c in fe_single_test (flag_name=0x11f98 "FE_INEXACT", fe_exc=1)
    at test-fenv.c:607

#4 0x00011664 in feenv_tests () at test-fenv.c:625 #5 0x000116e4 in main () at test-fenv.c:654

randolph

Signature · 4 lines
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^
#2 lore raw
Quoted 10 lines

eh? that's the output report file :)

i get a floating point exception when running the corresponding executable.

Program received signal SIGFPE, Arithmetic exception. 0x4011b328 in vfprintf () from /lib/libc.so.6 (gdb) bt

Quoted 10 lines
#0  0x4011b328 in vfprintf () from /lib/libc.so.6
#1  0x40123490 in printf () from /lib/libc.so.6
#2  0x00010f8c in feenv_mask_test (
    flag_name=0x40210048 "@\036\177P@\036\177T@\036\177`@\036\177X@\036\177h@\036\177\220@\036\177Ð@\036\177Ô@\036\177Ø@\036\177à@\036\177è@\036\177ø@\036\177ð@\036\200", fe_exc=1) at test-fenv.c:332
#3  0x0001160c in fe_single_test (flag_name=0x11f98 "FE_INEXACT", fe_exc=1)
    at test-fenv.c:607

#4 0x00011664 in feenv_tests () at test-fenv.c:625 #5 0x000116e4 in main () at test-fenv.c:654

When running these tests, it gets a little complex. I'm pretty sure the test needs to be run against the libc.so.6 that you are building, and not the one in /lib on your system.

You could set the LD_LIBRARY_PATH to the location of the objects you are building and then run it...

However, if you do that, then gdb might act strangely with this newly built libc (since ld trying to load gdb will use the libc in the library path).

How do you load gdb with one libc and debug a program that uses another?

When I run the test-fenv, I get a whole list of output criteria, but it finally exist with $?=132 I'm running with LD_LIBRARY_PATH set to the new libc, glibc 2.2.4-2, built with newer binutils.

c.

#3 lore raw
Quoted 9 lines · Carlos O'Donell Jr.

You could set the LD_LIBRARY_PATH to the location of the objects you are building and then run it...

However, if you do that, then gdb might act strangely with this newly built libc (since ld trying to load gdb will use the libc in the library path).

How do you load gdb with one libc and debug a program that uses another?

run gdb, then type
set env LD_LIBRARY_PATH blah blah blah

Signature · 1 line
Revolutions do not require corporate support.