make check in glib comes in last.
make check depends on the desktop-file-utils-0.20, which in turn depend on an installed glib, so that one should make sure that the desktop-file-utils are installed, working and at a correct version before running
make check. The canonical way would be to first install the new glibc, then desktop-file-utils, and then, at the very end, do
In general, an error during check is a reason to worry, at least in a professional setting. Failure of a test may mean that some particular condition can bring the system to its knees, even if the system runs fine 99.99% of the time.
In this particular case, you can directly look into the source code of glib to understand what is happening. Here is the relevant function:
/* test that thread creation fails as expected,
* by setting RLIMIT_NPROC ridiculously low
struct rlimit ol, nl;
getrlimit (RLIMIT_NPROC, &nl);
nl.rlim_cur = 1;
if ((ret = prlimit (getpid(), RLIMIT_NPROC, &nl, &ol)) != 0)
g_error ("prlimit failed: %s\n", g_strerror (ret));
error = NULL;
thread = g_thread_try_new ("a", thread1_func, NULL, &error);
g_assert (thread == NULL);
g_assert_error (error, G_THREAD_ERROR, G_THREAD_ERROR_AGAIN);
if ((ret = prlimit (getpid (), RLIMIT_NPROC, &ol, NULL)) != 0)
g_error ("resetting RLIMIT_NPROC failed: %s\n", g_strerror (ret));
The error occurs ad the line
g_assert( thread == NULL ) ;
The test function changes the RLIMIT_PROC to a value of 1 (
nl.rlim_cur=1, which limits the number of threads the current process can have). With that setting, creation of a new thread (
g_thread_try_new() call) should fail and return
NULL. For some reason, this does not happen.
Either there is a bug in the test suite, or a problem with glibc, or there was a problem correctly building glibc. In any case, incorrect return values from thread management library calls would make me very nervous.