Problems linking statically with libX11
Hi, I am trying to statically link an application we develop and I am getting a lot of warnings by linking: /usr/lib/qt3/lib/libqt.a(qfileinfo_unix.o)(.text+0x52a): In function `QFileInfo::group() const': : warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/qt3/lib/libqt.a(qfiledialog.o)(.text+0x8c27): In function `QFileDialog::setDir(QString const&)': : warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/qt3/lib/libqt.a(qapplication_x11.o)(.text+0x16e9): In function `sm_performSaveYourself(QSessionManagerData*)': : warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libX11.a(GetDflt.o)(.text+0x9a): In function `GetHomeDir': : warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libX11.a(GetDflt.o)(.text+0xea): In function `GetHomeDir': : warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libICE.a(transport.o)(.text+0x51b): In function `_IceTransSocketOpen': : warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libICE.a(transport.o)(.text+0x2b02): In function `_IceTransGetPeerNetworkId': : warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libICE.a(transport.o)(.text+0x326a): In function `_IceTransSocketINETConnect': : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libICE.a(transport.o)(.text+0x183a): In function `_IceTransSocketINETCreateListener': : warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking collect2: ld returned 1 exit status make[2]: *** [crysvun] Error 1 This happens on an up-to-date SuSE Linux 9.3. (i686) Any help will be appreciated. Regards, G. Ardelean.
Gheorghe Ardelean <ardelean@ww.uni-erlangen.de>:
: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
You can't link an app statically that uses any of the functions for name resolution, as these use the libnss* mechanism which requires dynamically loaded modules. So such apps still need the libnss* modules *they were linked to* to be available. My recommendation: either use something like dietlibc (but then all needed libraries need also to be linked against it) or simply don't link glibc statically. Philipp
Hi, Thank you for your answer. Statically linking worked for me with SuSE 8.2. Now, as I try to switch our machines to 9.3 I've got this problem. For the moment I'll postpone the upgrades to SuSE 9.3 Regards, G. Ardelean On Mon, 25 Jul 2005, Philipp Thomas wrote:
Gheorghe Ardelean <ardelean@ww.uni-erlangen.de>:
: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
You can't link an app statically that uses any of the functions for name resolution, as these use the libnss* mechanism which requires dynamically loaded modules. So such apps still need the libnss* modules *they were linked to* to be available.
My recommendation: either use something like dietlibc (but then all needed libraries need also to be linked against it) or simply don't link glibc statically.
Philipp
Gheorghe Ardelean <ardelean@ww.uni-erlangen.de>:
Statically linking worked for me with SuSE 8.2.
The problem was the same back then, just that you didn't get the warning!
For the moment I'll postpone the upgrades to SuSE 9.3
As the problems are the same, let me state once again that statical linking with the glibc is only possible if you do not use any function for name resolving, as even when glibc is linked statically, the libnss* modules are still loaded dynamically. As you have the same problems with 8.2, I'd strongly recommend going to 9.3 with it's much better gcc. Philipp
It is tricky to link binaries under a suse environment. I've been doing software development under suse for years. The results are always variable, since waht works for a release may not work for another. Your options are to link statically as many libs as you can or give up statically linked apps. Another alternative is to include copies of the libraries you cannot link statically with your application's package. The bottom-line is that building statically linked binaries under Linux is not well supported. Do you really need statically linked binaries? -- Rafael
On Monday 25 July 2005 22:22, Rafael E. Herrera wrote:
It is tricky to link binaries under a suse environment. I've been doing software development under suse for years.
I wouldn't go as far as blaming SuSE for static linking being tricky. Linux and its supporting software is under generally intensive development all the time. So, libraries change frequently and inevitably someone add an improvement that breaks an interface between objects. That same sort of joy has been experienced by Windows programmers, so it's not exclusive to linux/unix.
The results are always variable, since waht works for a release may not work for another.
Your options are to link statically as many libs as you can or give up statically linked apps.
Another alternative is to include copies of the libraries you cannot link statically with your application's package.
The bottom-line is that building statically linked binaries under Linux is not well supported. Do you really need statically linked binaries?
Static linking is as well supported under Linux as any other operating system. The "problem" is the rapid development and improvements to the software. The general rule is to only statically link programs that will run on the exact same architecture and library set as the machine doing the building. (or be very careful with a cross compile.) If you can reduce static linking down to linking only libraries that do not depend on any other libraries then results are more stable. We have a couple of statically built apps at work (Solaris). Test systems, development systems, and production systems are all configured identically, so there has never been an architecture or upgrade related problem that stopped production.
Synthetic Cartoonz <synthetoonz@bellsouth.net>:
We have a couple of statically built apps at work (Solaris).
Ha, it was Sun that developed the nsswitch concept, i.e. configurable means to do name resolving and their linker will simply refuse all linking if such functions are used in statically linked binaries. Philipp
participants (4)
-
Gheorghe Ardelean -
Philipp Thomas -
Rafael E. Herrera -
Synthetic Cartoonz