The miserable process of Linux static link to MySQL glibc library-mango log-Netease blog

The miserable process of Linux static link to MySQL glibc library-mango log-Netease blog

Miserable process of Linux static link to MySQL glibc Library  

19:09:31| Category:Default category| Tag:Linux static Link Static linking glibc |Font Size LargeMediumSmall Subscription

In the past two days, we need to make the project a static link version to facilitate running on various Linux platforms of various companies.

I think this is not simple. Just add a-static Link parameter, but it will take much longer to solve a series of problems than I expected.

Development Environment:

Centos release 5.8 (final)

GCC (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)

The problem is caused by the static connection to the MySQL database. The parameters for connecting to the MySQL database are as follows:

Lib_mysql =$ (shell mysql_config -- libs)

The static link is found to be tragic. Hundreds of Link errors are all undefined and require the krb5 library. Link with the krb5 Library:

Lib_kbr5 = $ (shell krb5-config -- libs)

The final link parameters are as follows:$ (Lib_mysql) $ (lib_kbr5) $ (lib_thread)-static

Result: The linker still reports the following error:

/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_get_principal ':
(. Text + 0 xfaa): Undefined reference to 'keyctl _ read_alloc'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_getkeycount ':
(. Text + 0x1129): Undefined reference to 'keyctl _ read'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_1_ache ':
(. Text + 0x1194): Undefined reference to 'keyctl _ clear'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_1_ache ':
(. Text + 0x11c1): Undefined reference to 'keyctl _ clear'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_resolve ':
(. Text + 0x1692): Undefined reference to 'request _ key'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_resolve ':
(. Text + 0x16bb): Undefined reference to 'keyctl _ read'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_resolve ':
(. Text + 0x170c): Undefined reference to 'keyctl _ search'
/Usr/lib64/libkrb5.a (cc_keyring.o): In function 'krb5 _ krcc_resolve ':
(. Text + 0x1733): Undefined reference to 'add _ key'

......

The next step is to check whether there are any databases missing and what is added when there is any link missing. The undefined cannot be completely eliminated. It's depressing. I just need to link the MySQL database statically. Isn't that all right?

After a long time of hard work, I still described the problem to a friend who asked me if I was using Yum to automatically install MySQL, or if I had to download the MySQL source code package by myself, how can I manually compile and install it? Download mysql-5.5.29.tar.gz, run tar-xvf, cmake, make, and make install, and manually specify the connection parameters of MySQL:
Lib_mysql =/usr/local/MySQL/lib/libmysqlclient.

Haha, there is no need to link the krb5 library, but there are several new undefined, but fortunately there are only a few, and they are clear:

/Usr/local/MySQL/lib/libmysqlclient. A (client_plugin.c.o): In function 'add _ plugin ':
/Home/RSM/mysql-5.5.29/SQL-Common/client_plugin.c: 178: Undefined reference to 'dlclose'
/Usr/local/MySQL/lib/libmysqlclient. A (client_plugin.c.o): In function 'mysql _ load_plugin_v ':
/Home/RSM/mysql-5.5.29/SQL-Common/client_plugin.c: 354: Undefined reference to 'dlopen'
/Home/RSM/mysql-5.5.29/SQL-Common/client_plugin.c: 382: Undefined reference to 'dlsym'
/Home/RSM/mysql-5.5.29/SQL-Common/client_plugin.c: 374: Undefined reference to 'dlerror'
/Home/RSM/mysql-5.5.29/SQL-Common/client_plugin.c: 385: Undefined reference to 'dlclose'

Therefore, libdl. A (in glibc) is added to the Linked Library. Some link parameters are as follows:

-Lcrypt-L/usr/local/MySQL/lib/-lmysqlclient-LDL-lpthread-static

Oh, I finally got the link! Although there are several annoying Warnings:

/Usr/local/MySQL/lib // libmysqlclient. A (client_plugin.c.o): In function 'mysql _ load_plugin_v ':
/Home/win/mysql-5.5.29/SQL-Common/client_plugin.c: 354: Warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/Usr/local/MySQL/lib // libmysqlclient. A (mf_pack.c.o): In function 'expand _ tilde ':
/Home/win/mysql-5.5.29/mysys/mf_pack.c: 387: Warning: Using 'getpwnam 'in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/Usr/local/MySQL/lib // libmysqlclient. A (libmysql. c. O): In function 'read _ user_name ':
/Home/win/mysql-5.5.29/libmysql. C: 422: Warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/Usr/local/MySQL/lib // libmysqlclient. A (mf_pack.c.o): In function 'expand _ tilde ':
/Home/win/mysql-5.5.29/mysys/mf_pack.c: 389: Warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/Usr/local/MySQL/lib // libmysqlclient. A (client. c. O): In function 'mysql _ real_connect ':
/Home/win/mysql-5.5.29/SQL-Common/client. C: 3247: Warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/Usr/lib/GCC/x86_64-redhat-linux/4.4.6 /.. /.. /.. /.. /lib64/libpthread. A (libpthread. o): In function 'sem _ open ':
(. Text + 0x764d): warning: the use of 'mktemp 'is dangerous, better use 'mkstemp'
/Usr/local/MySQL/lib // libmysqlclient. A (libmysql. c. O): In function 'mysql _ server_init ':
/Home/win/mysql-5.5.29/libmysql. C: 153: Warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

So the process was excited. When it got up, it went down !!!! Using GDB, we found that the library that calls libdl was down.

In fact, the last six of the above seven warnings I know: In another previous project (the environment is Ubuntu server), it is also a static link, there are always the following six warnings, but these functions are not used, so there is no problem with the process. At that time, the project progress was exceptionally tight, we have never been tempted to study these warnings. The new first warning, in which dlopen will be called, will cause downtime, which cannot be escaped, so I will focus on eliminating these warnings.

This is a common problem: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking:

Static linking issue with glibc

However, I searched Google by combining various keywords and found many people asking this question. The discussion was enthusiastic, but no one provided a solution to the problem. The following two connections are clear:

Http://bytes.com/topic/c/answers/877929-lnk-error-using-dlopen-statically-linked-apps-requires-runtime-shared-lib

Https://bugzilla.redhat.com/show_bug.cgi? Id = 111298

Http://www.qtcentre.org/threads/32521-Problems-with-static-linking-gt-segmentation-fault

A foreigner mentioned the following section:

Jakub Jelinek 2003-12-01 17:49:41 est

If a rhl9 built statically linked binary using NSS works on older glibcs, then you are just lucky, nothing else. it certainly will not work on all older glibcs, only on some and only under some circumstances. statically linked programs which are not self-contained and depend on the installed glibc (be it because of using NSS or iconv (which both dlopen glibc internally ), using dlopen directly or even using locale Support) are really the least portable thing you can build. dynamically linking is uncomparably more portable. you can link some libraries statically using-bstatic-lfoo-lbar-bdynamic, yet link against the crucial system libraries dynamically. the warnings were added so that everyone is aware of the problems with-static. for statically linked binaries using NSS/iconv/dlopen the dynamic linker needs to be compiled into the statically linked program, yet the shared libraries it loads come from a different glibc if the statically linked binary is moved onto a different system. this means the glibc private interface between the dynamic linker and libc. so/libpthread. so is exposed, but this interface is constantly changing (and has been changing for years in the past as well ). so, the only supported way of using NSS/iconv/dlopen in statically linked programs is if they are compiled/linked against the same glibc as they are run.

Search to open this page:

Http://www.google.com.hk/search? Hl = en & source = HP & Q = Using + 'gethostbyname' + in + statically + linked + applications + requires + at + runtime + the + Shared + libraries + from + the + glibc + version + used + for + linking & AQ = F & OQ = & AQI =

However, warning still exists. A friend also reminded me that there is a problem with installing the system version? Or is there a problem with the development environment? Okay, I have no better way. I also asked it colleagues to reinstall the new environment centos6.3 on the computer. after a long time of hard work, compilation, links, and the result is the seven warnings, they are there!

In the end, this problem cannot be solved. However, the project had to continue, so a compromise was finally adopted:

Static connections between MySQL and other self-owned libraries, glibc, libstdc ++, and other common basic library dynamic links.

-Wl,-DN other static libraries-L/usr/local/MySQL/lib/-lmysqlclient-wl,-dy-lpthread-LDL-lcrypt

It is said that this is the standard practice ~~ Why do I need to link the glibc library statically?

Of course, you can also directly compile the static library into the project at the compilation stage, for example:

G ++ main. cpp libmysqlclient.