This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: tst-getaddrinfo4 failure with glibc-2.18
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Allin Cottrell <cottrell at wfu dot edu>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-help <libc-help at sourceware dot org>
- Date: Thu, 15 Aug 2013 22:30:56 +0530
- Subject: Re: tst-getaddrinfo4 failure with glibc-2.18
- References: <alpine dot LNX dot 2 dot 03 dot 1308141222580 dot 1968 at wfu dot edu> <CAE2sS1jURE7KJCMbLqkZeQHLz5N5LV2ygY8CXBWosL0+NfRY8A at mail dot gmail dot com> <alpine dot LFD dot 2 dot 03 dot 1308141606420 dot 2742 at wfu dot edu> <alpine dot LFD dot 2 dot 03 dot 1308141624190 dot 3078 at wfu dot edu> <520BE867 dot 5060304 at redhat dot com> <alpine dot LNX dot 2 dot 03 dot 1308151104040 dot 652 at wfu dot edu> <alpine dot LNX dot 2 dot 03 dot 1308151234310 dot 554 at wfu dot edu>
On 15 August 2013 22:21, Allin Cottrell <cottrell@wfu.edu> wrote:
> I should have said: this is on a system with 64-bit kernel and 32-bit
> userspace. I'm seeing something that may be related at
>
> http://www.linuxquestions.org/questions/linux-from-scratch-13/glibc-2-18-and-acroread-4175473288
>
> I last built and installed glibc-2.17 in January, since when I've updated
> gcc (4.8.1) and kernel headers (3.10.7). So I just tried the experiment of
> rebuilding 2.17 under my current setup, to check that nothing had gone
> screwy in the meantime in regard to my ability to build a properly
> functioning glibc. Result: all OK, the system is stable with glibc-2.17 as
> rebuilt today. But it's seriously unstable with glibc-2.18 as built with the
> same toolchain and configure options, namely:
>
> ../glibc-2.17/configure --build=i686-pc-linux-gnu \
> --prefix=/usr --with-tls \
> --disable-profile --enable-add-ons \
> --enable-kernel=3.10.7
Please file a detailed bug report describing this, including some
minimal steps to reproduce the problem, on the lines of:
1. Build glibc with specific configuration options
2. Using test-run.sh in the build directory, run the program foo:
./testrun.sh /usr/bin/foo
where foo is as simple a program as you can get it to be and (more
importantly) its source is available. If you can write a test program
that reproduces the code, it would be the ideal situation.
Siddhesh
--
http://siddhesh.in