Is there any distribution that provide statically linked glib libraries ? I need to ship my application to a glibc-2.7 based system , which caused everything build against glibc-2.1X failed to run , iostream issue. So i had to statically link everything.
Both libxcb and glib failed for missing symbols:
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x1c): undefined reference to `glib_mem__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x68): undefined reference to `glib_mem__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0xb0): undefined reference to `glib_mem__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0xfc): undefined reference to `glib_mem__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x144): undefined reference to `glib_mem__realloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x194): undefined reference to `glib_mem__realloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x1e0): undefined reference to `glib_mem__free_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x218): undefined reference to `glib_mem__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gmem.o):(.note.stapsdt+0x264): undefined reference to `glib_mem__realloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gslice.o):(.note.stapsdt+0x1c): undefined reference to `glib_slice__alloc_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gslice.o):(.note.stapsdt+0x60): undefined reference to `glib_slice__free_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x1c): undefined reference to `glib_quark__new_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x5c): undefined reference to `glib_quark__new_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x9c): undefined reference to `glib_quark__new_semaphore'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/libglib-2.0.a(gdataset.o):(.note.stapsdt+0xdc): undefined reference to `glib_quark__new_semaphore'
collect2: ld returned 1 exit status
make: *** [StreetBasketBall] Error 1
A lot of people run into same issue above , i googled and found a bug report which insists on adding -lrt to ld , but sadly , i checked the output of pkg-config , it contains that already.
How can i solve this problem ? Or is there any other distribution available for me ?
Thanks !
P.S: USE="-static-libs" is enabled in make.conf
GTK and its Glib is licensed under the LGPL license.
The LGPL license requires that any combined work (i.e. a program linking the Glib) should "not restrict modification of the portions of the Library" and explicitly suggests to "Use a suitable shared library mechanism" for that goal. The intent is that any user of a software linked with Glib should be able to improve easily Glib (e.g. update it) and be able to use the software linked with the improved Glib.
In practical terms, Glib sort-of needs to be a shared library, and if you distribute a binary statically linked with a variant of Glib, you should provide the source of your Glib and enough files so that the user would be able to relink against a new Glib (i.e. all the object files of your application).
So you are unlikely to find a statically linked version of Glib, because it is sort-of "illegal" (and against the goal of the LGPL and the FSF).
A distribution certainly won't facilitate the violation of the LGPL license by giving static Glib libraries.
Caveat: I am not a lawyer
PS. To solve your issue, you might try to statically link only the libc (but it probably won't work, because Glib uses libdl for dlopen which sort-of needs to be dynamically linked).
You could make your software a free software (e.g. GPL licensed) and distribute its source code (leaving the burden of building it and packaging it to users or to distribution makers).
If you insist on shipping binaries, make several variants of them: one for old systems (with libc <= 2.7) and one for newer systems.