Skip to content


Subversion checkout URL

You can clone with
Download ZIP


linux: use getaddrinfo_a() if available #617

bnoordhuis opened this Issue · 3 comments

2 participants


getaddrinfo_a() has been in glibc since forever but other libcs (uclibc, dietlibc) don't have it. Use something like this to look it up:

// look for the lib in a few places
void *handle = dlopen("/path/to/");

 // use versioned symbol to avoid ABI issues
void *addr = dlsym(handle, "getaddrinfo_a", "GLIBC_2.2.5");
@bnoordhuis bnoordhuis was assigned

What will happen with the dlopen check when the binary has a libc statically linked into it (e.g. musl). I suspect that loading will also load (and use) glibc. Having two different libc's linked into a single program sounds like trouble to me. And, preferably, statically linked binaries shouldn't have dlsym() included in the first place.

I'd prefer a compile-time check, similar to autoconf AC_SEARCH_LIBS(). Should other libc's implement getaddrinfo_a() in the future, then those will be used automatically as well. Alternatively, some compile-time macro to disable the dlopen() search is fine, too.


Having two different libc's linked into a single program sounds like trouble to me.

You're probably right. We don't do configure-time checks though so that's not an option.

I'll see if I can get it to work with simple #ifdef __GLIBC__ guards.


Okay, I've decided against using getaddrinfo_a(). The problem with that function is that it either spawns a thread or sends a signal. The former is undesirable because libuv has only limited possibilities for batching lookups and we don't want to spawn a million threads, the latter because signals and libraries create headaches for the user.

@bnoordhuis bnoordhuis closed this
@saghul saghul referenced this issue in libuv/libuv

[2.0 RFC] Thread pool handle #7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.