Skip to content
This repository

linux: use getaddrinfo_a() if available #617

Closed
bnoordhuis opened this Issue · 3 comments

2 participants

Ben Noordhuis Yoran Heling
Ben Noordhuis

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/libanl.so");

 // use versioned symbol to avoid ABI issues
void *addr = dlsym(handle, "getaddrinfo_a", "GLIBC_2.2.5");
Yoran Heling

What will happen with the dlopen check when the binary has a libc statically linked into it (e.g. musl). I suspect that loading libanl.so 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.

Ben Noordhuis

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.

Ben Noordhuis

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.

Ben Noordhuis bnoordhuis closed this
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.