Linker warnings while building application against

问题:

I am trying to build mysql-connector-c from source(per instructions here) and statically link against the library in my application. However I am getting the following warnings and I was wondering if anyone has any ideas as to why this is:

/path/to/lib/libmysqlclient.a(mf_pack.c.o): In function `unpack_dirname':
mf_pack.c:(.text+0x90b): warning: Using 'getpwnam' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
/path/to/lib/libmysqlclient.a(libmysql.c.o): In function `read_user_name':
libmysql.c:(.text+0x2b06): warning: Using 'getpwuid' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
/path/to/lib/libmysqlclient.a(mf_pack.c.o): In function `unpack_dirname':
mf_pack.c:(.text+0x916): warning: Using 'endpwent' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
/path/to/lib/libmysqlclient.a(client.c.o): In function `mysql_real_connect':
client.c:(.text+0x305c): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
/path/to/lib/libmysqlclient.a(libmysql.c.o): In function `mysql_server_init':
libmysql.c:(.text+0x2f9b): warning: Using 'getservbyname' in statically linked
applications requires at runtime the shared libraries from the glibc version 
used for linking

Here are some of the relevant args/flags:

For building the library CMake is being passed in the following:

-G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/path/to/my/install/root -DCMAKE_C_FLAGS="-m64" -DCMAKE_CXX_FLAGS="-m64"

For building the application:

CFLAGS := $(CFLAGS) -Werror -Wall -ggdb -gdwarf-2
LDFLAGS := $(LDFLAGS) -static -ggdb -gdwarf-2

回答1:

These warnings occur because the GLibC functions in question use the GLibC Name Service Switch (NSS) mechanism internally:

The basic idea is to put the implementation of the different services offered to access the databases in separate modules. This has some advantages:

1. Contributors can add new services without adding them to the GNU C Library.
2. The modules can be updated separately.
3. The C library image is smaller.

To fulfill the first goal above the ABI of the modules will be described below. For getting the implementation of a new service right it is important to understand how the functions in the modules get called. They are in no way designed to be used by the programmer directly. Instead the programmer should only use the documented and standardized functions to access the databases.

Since the NSS mechanism relies on dynamic linking to work, you need the appropriate NSS modules (most of which come with glibc) at runtime in order to be able to use these functions, irrespective of whether you have statically or dynamically linked to the C library itself. The warnings are there to alert you that you really will need those modules at runtime; trying to run the linked binary on a box with no NSS modules on it will fail at runtime with an error from ld.so complaining that it can't find 'libnss_files.so.2' or some other thing of that ilk.

回答2:

Perhaps you should statically link with glibc: -static-libgcc.