Use of __pthread_get_minstack leads to unnecessarily strict libc6 versioned dependency on Debian

[andersk]

The Rust libraries gained a dependency on the private glibc symbol __pthread_get_minstack in #6233; it was reverted in #11331 and reinstated in #11885 (“Alright, let's merge this and then we can see how big the impact is.”). Here’s part of the impact that may not have been considered:

The Debian package build system includes a tool dpkg-shlibdeps that scans all binaries and libraries to be included in a package to infer dependency information for shared libraries. Based on the symbol information in /var/lib/dpkg/info/libc6:amd64.symbols, the use of __pthread_get_minstack@GLIBC_PRIVATE is translated into a strict versioned dependency on the exact version of libc6 that the package was built against:

$ cat thread-test.rs
use std::thread;
fn main() {
    thread::scoped(move || {println!("Hello, world!")}).join();
}
$ rustc thread-test.rs
$ mkdir debian; touch debian/control
$ dpkg-shlibdeps -v -v thread-test
…
 Looking up symbol madvise@GLIBC_2.2.5
 Found in symbols file of libc.so.6 (minver: 2.2.5, dep: libc6 #MINVER#)
 Looking up symbol pthread_mutex_unlock@GLIBC_2.2.5
 Found in symbols file of libpthread.so.0 (minver: 2.2.5, dep: libc6 #MINVER#)
 Looking up symbol __pthread_get_minstack@GLIBC_PRIVATE
 Found in symbols file of libpthread.so.0 (minver: 0, dep: libc6 (>> 2.19), libc6 (<< 2.20))
 Looking up symbol _Unwind_FindEnclosingFunction@GCC_3.3
 Found in symbols file of libgcc_s.so.1 (minver: 1:4.1.1, dep: libgcc1 #MINVER#)
 Looking up symbol strncmp@GLIBC_2.2.5
 Found in symbols file of libc.so.6 (minver: 2.2.5, dep: libc6 #MINVER#)
…
$ cat debian/substvars
shlibs:Depends=libc6 (>= 2.18), libc6 (>> 2.19), libc6 (<< 2.20), libgcc1 (>= 1:4.1.1)

What this means in practice is that a Debian package containing threaded Rust code built on one release of Debian or Ubuntu will not be installable on any other release. Trying to upgrade to a new release while such a package is installed will cause dependency errors.

(What caused me to notice this problem is that the rust-nightly package for Ubuntu 14.10 in ppa:hansjorg/rust is no longer installable on Ubuntu 15.04 after a libc6 upgrade.)

[huonw]

Ah, this is annoying. Do you happen to know of a way that we can avoid the strict dependency while still calling __pthread_get_minstack or do we have to just remove it entirely?

(It is used as a weak symbol atm.)

[huonw]

triage: I-nominated

[andersk]

I guess one horrible solution would be to look up the symbol with dlsym().

#include <dlfcn.h>
#include <pthread.h>
#include <stdio.h>
#include <string.h>

int main()
{
    pthread_attr_t attr;
    pthread_attr_init(&attr);
    memset(&attr, 0, sizeof(attr));
    void *handle = dlopen(NULL, RTLD_LAZY);
    size_t (*__pthread_get_minstack)(const pthread_attr_t *attr) =
        dlsym(handle, "__pthread_get_minstack");
    if (__pthread_get_minstack != NULL)
        printf("%zd\n", __pthread_get_minstack(&attr));
    dlclose(handle);
    pthread_attr_destroy(&attr);
    return 0;
}

$ gcc -Wall minstack.c -ldl -lpthread -o minstack
$ ./minstack
24640
$ dpkg-shlibdeps minstack
dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory
$ cat debian/substvars
shlibs:Depends=libc6 (>= 2.4)

[andersk]

BTW, dlsym() is how we used to do this, until commit 699b33d, so I feel less horrible about this now.