This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Just a quick status-update: the new-syscall-stub-enabled libc now passes all checks (apart from a previously-exiting locale-related failure) and it all seems to work nice and stable. The NPTL test suite combined with the new syscall stubs turned out to be a really tough test-case, because it stressed lots of things in ways that wasn't possible before. As a result, bugs got fixed in libc, gcc (one still pending), libunwind, and the kernel. The only outstanding issue now is that of libgcc_eh.a. The problem is that since libgcc_eh.a references the unwinder, you'll have to link in -lunwind when linking in libgcc_eh.a. My understanding is that libgcc_eh.a should only be linked into statically-linked applications. When doing so, linking in libunwind.a seems reasonable enough. However, at the moment, the libc build environment seems to sometime link libgcc_eh.a even into dynamically linked binaries and in that case, you really don't want to have to link in libunwind.a. For now, I hacked around the problem by putting the libunwind.a members into libgcc_eh.a, but that's of course not a clean solution. A related issue: when building a statically linked binary, shouldn't the NPTL unwinder also use the static libgcc_eh.a facilities, rather than loading libgcc_s.so at runtime? Doing the latter can result in rather difficult to track down bugs when there is a version conflict between libgcc_eh.a and libgcc_s.so. Comments? --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |