I need to run flom on a linux with glibc-2.12. I cannot upgrade it to 2.14, which is the version required by flom. I have built the flom-0.7.1 with statically linked glibc:
./configure CFLAGS="-static"
make
It works. However after the problem with dynamic network mode was fixed in the 0.9.0 alpha (see this thread), I wanted to build the new version the same way (ie. statically linked glibc) and it doesn't work. The resulting binary is dynamically linked with glibc.
I have also tried adding "-static" to GLIB2_CFLAGS (which is by default equal to "-pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include"):
./configure CFLAGS="-static -O2 -g" GLIB2_CFLAGS="-static -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include"
make
After trying to launch the binary I get:
$ ./flom
./flom: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./flom)
$ ls -al /lib64/libc.so.6
lrwxrwxrwx. 1 root root 12 Jul 6 2012 /lib64/libc.so.6 -> libc-2.12.so
What has changed since version 0.7.1, so that CFLAGS="-static" is no longer enough to make the statically linked binary?
Is there another approach (besides statically linking glibc) of running flom on the linux with glibc-2.12?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so it seems not a viable solution.
I might backport the little fix related to dynamic network bug on 0.7.1 and release a new maintenance level 0.7.2, but you would not be able to migrate to 0.9 version of FLoM in the next future...
At this time I don't have a better solution for your issue: I develop the software using an old Ubuntu 10.04 to minimize this type of problems, but your glib level is really low and does not supply some necessary features.
Googling the web I've found out that libtool link mode should support "-all-static" mode args:
tiian@ubuntu:~/flom-code$ ./libtool --help --mode=link
Usage: libtool [OPTION]... --mode=link LINK-COMMAND...
Link object files or libraries together to form another library, or to
create an executable program.
LINK-COMMAND is a command using the C compiler that you would use to create
a program from several object files.
The following components of LINK-COMMAND are treated specially:
-all-static do not do any dynamic linking at all
-avoid-version do not add a version suffix if possible
...
I've tried some hacks but I was not able to pass "-all-static" mode-arg to libtool from Makefile.am (automake): you could try this solution path too...
Last edit: Christian Ferrari 2014-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The version of libc shipped with RedHat 6.5 is 2.12: http://distrowatch.com/table.php?distribution=redhat
RHEL-6.5: libc-2.12
RHEL-7.0: libc-2.17
The upgrade from RHEL-6.5 (I am using now) to RHEL-7.0 is unlikely in the near future.
I tested the solution and it works! It compiles with statically linked libc and the dynamic network mode works as expected. Then I created a pull request. I'm not sure if the pull request is correct, because the github says "This pull request contains merge conflicts that must be resolved." I suppose the request wasn't applied to the 0.7.1 tag, but to the master branch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, but I'm missing the point.
This is the version of glibc (libc6) of Ubuntu 10.04 at the current patch level:
tiian@mojan:~/src/flom$ dpkg -l| grep libc6
ii libc6 2.11.1-0ubuntu7.17 Embedded GNU C Library: Shared libraries
ii libc6-amd64 2.11.1-0ubuntu7.17 GNU C Library: 64bit Shared libraries for AM
ii libc6-dbg 2.11.1-0ubuntu7.17 Embedded GNU C Library: detached debugging s
ii libc6-dev 2.11.1-0ubuntu7.17 Embedded GNU C Library: Development Librarie
ii libc6-dev-amd64 2.11.1-0ubuntu7.17 GNU C Library: 64bit Development Libraries f
ii libc6-i686 2.11.1-0ubuntu7.17 GNU C Library: Shared libraries [i686 optimi
it's 2.11.1, older than 2.12
I don't understand what's flom is using to ask for libc 2.14 or upper on your RHEL 6.5, but I'm supposing the caveat is somewhere else: RHEL 6.5 is not "ancient" at all! Ubuntu 10.04 is older that it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might be doing something wrong, but when I build the flom on my computer:
./configure
make
and then I copy the executable to RHEL-6.5 and execute it I get the following error:
$ ./flom
./flom: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./flom)
I assumed the error message means I need to have glibc 2.14 on RHEL-6.5 in order for it to work.
My computer: /lib/x86_64-linux-gnu/libc-2.18.so
RHEL-6.5: /lib/libc-2.12.so and /lib64/libc-2.12.so
Is the version on my computer important at all? Would it make any difference if I compiled flom on the older OS with libc-2.12?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a rule of thumb, if you want to take advantage of binary compatibility, you should use the oldest system as the build system.
If the newer system do not introduce backward incompatibilities, it will be able to execute the binary objects produced by the older system.
Many commercial closed source softwares use this metodology.
Last edit: Christian Ferrari 2014-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I merged your Github pull request with some other fixes introduced in release 0.9.0 and released 0.7.2
In the meantime I hope you have been able to use 0.9.0 on all your systems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I need to run flom on a linux with glibc-2.12. I cannot upgrade it to 2.14, which is the version required by flom. I have built the flom-0.7.1 with statically linked glibc:
./configure CFLAGS="-static"
make
It works. However after the problem with dynamic network mode was fixed in the 0.9.0 alpha (see this thread), I wanted to build the new version the same way (ie. statically linked glibc) and it doesn't work. The resulting binary is dynamically linked with glibc.
I have also tried adding "-static" to GLIB2_CFLAGS (which is by default equal to "-pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include"):
./configure CFLAGS="-static -O2 -g" GLIB2_CFLAGS="-static -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include"
make
After trying to launch the binary I get:
$ ./flom
./flom: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./flom)
$ ls -al /lib64/libc.so.6
lrwxrwxrwx. 1 root root 12 Jul 6 2012 /lib64/libc.so.6 -> libc-2.12.so
The minimum level of glib2 is 2.22 as explained here: http://sourceforge.net/p/flom/tickets/1/
FLoM 0.9.0 will introduce "libflom" to develop custom programs that can interface a flom daemon; libflom is build using libtool.
This sequence:
produces a static libflom library and links it against flom executable, but on my system it links the other libraries using shared versions:
tiian@ubuntu:~/flom-code$ ldd /usr/local/bin/flom linux-gate.so.1 => (0xb7701000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb76f1000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb76e8000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb761d000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7604000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb74a2000) libpcre.so.3 => /lib/libpcre.so.3 (0xb7471000) /lib/ld-linux.so.2 (0xb7702000)so it seems not a viable solution.
I might backport the little fix related to dynamic network bug on 0.7.1 and release a new maintenance level 0.7.2, but you would not be able to migrate to 0.9 version of FLoM in the next future...
At this time I don't have a better solution for your issue: I develop the software using an old Ubuntu 10.04 to minimize this type of problems, but your glib level is really low and does not supply some necessary features.
Googling the web I've found out that libtool link mode should support "-all-static" mode args:
I've tried some hacks but I was not able to pass "-all-static" mode-arg to libtool from Makefile.am (automake): you could try this solution path too...
Last edit: Christian Ferrari 2014-11-20
My problem is with libc (glibc), not with glib2.
The version of libc shipped with RedHat 6.5 is 2.12:
http://distrowatch.com/table.php?distribution=redhat
RHEL-6.5: libc-2.12
RHEL-7.0: libc-2.17
The upgrade from RHEL-6.5 (I am using now) to RHEL-7.0 is unlikely in the near future.
I understand that libc-2.12 is very old, December 2012 according to http://ftp.gnu.org/gnu/glibc/
I decided to go the backport route. I forked the repository on github, created a branch 0.7.1-dynnetfix, applied the changes from your commit.
Your commit:
https://github.com/tiian/flom/commit/1337eae274a8ad3ffaab89f555aa53867dd799ad
I tested the solution and it works! It compiles with statically linked libc and the dynamic network mode works as expected. Then I created a pull request. I'm not sure if the pull request is correct, because the github says "This pull request contains merge conflicts that must be resolved." I suppose the request wasn't applied to the 0.7.1 tag, but to the master branch.
Sorry, but I'm missing the point.
This is the version of glibc (libc6) of Ubuntu 10.04 at the current patch level:
it's 2.11.1, older than 2.12
I don't understand what's flom is using to ask for libc 2.14 or upper on your RHEL 6.5, but I'm supposing the caveat is somewhere else: RHEL 6.5 is not "ancient" at all! Ubuntu 10.04 is older that it.
I might be doing something wrong, but when I build the flom on my computer:
./configure
make
and then I copy the executable to RHEL-6.5 and execute it I get the following error:
$ ./flom
./flom: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./flom)
I assumed the error message means I need to have glibc 2.14 on RHEL-6.5 in order for it to work.
My computer: /lib/x86_64-linux-gnu/libc-2.18.so
RHEL-6.5: /lib/libc-2.12.so and /lib64/libc-2.12.so
Is the version on my computer important at all? Would it make any difference if I compiled flom on the older OS with libc-2.12?
As a rule of thumb, if you want to take advantage of binary compatibility, you should use the oldest system as the build system.
If the newer system do not introduce backward incompatibilities, it will be able to execute the binary objects produced by the older system.
Many commercial closed source softwares use this metodology.
Last edit: Christian Ferrari 2014-11-28
I merged your Github pull request with some other fixes introduced in release 0.9.0 and released 0.7.2
In the meantime I hope you have been able to use 0.9.0 on all your systems.