How does linker know what to link with a system call?

Question

When I was trying to compile squid by hand on a RHEL 5.5 server, run configure and got

configure: WARNING: Eep!  Cannot find epoll, kqueue, /dev/poll, poll or select!
configure: WARNING: Will try select and hope for the best.
configure: Using select for the IO loop.

Looks like the kernel is not configured with CONFIG_EPOLL. So I tried to compile this example epoll program to check whether it works.

On my gentoo box (which CONFIG_EPOLL is enabled.), it's compiled without any problem.

On the server, I got

/tmp/cc8PhJh0.o: In function 'main':
epoll-exmaple.c:(.text+0x262): undefined reference to 'epoll_create1'
collect2: ld returned 1 exit status

We all know for c program compiler looks for the definitions in *.h files and linker links them with *.so files.

My questions is, epoll_create1 is a system call to kernel. Which file exactly does linker search to locate the implementation to that system call?

Thanks.

Answer 1

It looks in the system C library (normally; a small handful of system calls are in other special libraries like librt). The C library provides a C API for userspace programs that handles making the system call for you. Sometimes this can be a very thin wrapper around the system call that just takes care of setting up and returning the arguments, but more frequently it has various glue that you don't want to have to worry about, such as differences in data sizes between userspace and the kernel, differences in implementation for the different architectures, backward or forward compatibility for changes in the kernel system call API, and so forth.

% readelf -s /lib/i386-linux-gnu/libc.so.6 | grep epoll_create1
  1837: 000d5280    52 FUNC    GLOBAL DEFAULT   12 epoll_create1@@GLIBC_2.9

If you look at the C library as above, you can see the C function that the linker is linking code against.