glibc version problem
log in

Advanced search

Message boards : Unix/Linux : glibc version problem

Author Message
Simone [3dz2]
Send message
Joined: 18 Nov 13
Posts: 6
Credit: 279,326
RAC: 0
Italy
Message 272 - Posted: 8 Jan 2014, 7:56:30 UTC

Hi!
Finally I found some time to run some of your wus :)
All wus failed because a glibc version problem. Your tngrid_expansion_v3_linux64 executable need glibc 2.14 but on my computer I have 2.13. My system is the last stable debian (Version 7.3 (wheezy) 64 bit) with Kernel Linux 3.2.0-4-amd64.
I see that the binary is dynamically linked, so maybe if you build a static executable the problem could be solved.
Bye!

Profile paolomorettin
Project developer
Project tester
Project scientist
Send message
Joined: 20 Nov 13
Posts: 19
Credit: 13,027
RAC: 0
Message 273 - Posted: 8 Jan 2014, 11:07:18 UTC - in response to Message 272.

Hi!
Finally I found some time to run some of your wus :)
All wus failed because a glibc version problem. Your tngrid_expansion_v3_linux64 executable need glibc 2.14 but on my computer I have 2.13. My system is the last stable debian (Version 7.3 (wheezy) 64 bit) with Kernel Linux 3.2.0-4-amd64.
I see that the binary is dynamically linked, so maybe if you build a static executable the problem could be solved.
Bye!


Hello and welcome! We will solve this issue as soon as possible, thank you!
____________
Paolo - Application team dev (SSC11)

"If you were plowing a field, which would you rather use: two strong oxen or 1024 chickens?" Seymour Cray

Simone [3dz2]
Send message
Joined: 18 Nov 13
Posts: 6
Credit: 279,326
RAC: 0
Italy
Message 323 - Posted: 22 Jan 2014, 19:40:40 UTC - in response to Message 273.

Version 4 have still this problem unsolved.
Interestingly, the 32bit version seem ok and the problem is only on the 64bit.

Profile [VENETO] sabayonino
Avatar
Send message
Joined: 21 Jan 14
Posts: 12
Credit: 2,096,193
RAC: 123
Italy
Message 326 - Posted: 22 Jan 2014, 22:54:23 UTC - in response to Message 323.
Last modified: 22 Jan 2014, 22:54:57 UTC

Version 4 have still this problem unsolved.
Interestingly, the 32bit version seem ok and the problem is only on the 64bit.


can you share ldd output for gene application ? (for both applications 32/64)
____________
Powered by Gentoo Linux
Kernel : 4.4.26-gentoo
KDE 16.04.3

Simone [3dz2]
Send message
Joined: 18 Nov 13
Posts: 6
Credit: 279,326
RAC: 0
Italy
Message 327 - Posted: 23 Jan 2014, 19:18:10 UTC - in response to Message 326.
Last modified: 23 Jan 2014, 19:18:28 UTC

tngrid_expansion_v4_linux32: linux-gate.so.1 => (0xf77de000) libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf7798000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf777b000) libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7761000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75fe000) /lib/ld-linux.so.2 (0xf77df000) tngrid_expansion_v4_linux64: ./tngrid_expansion_v4_linux64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./tngrid_expansion_v4_linux64) linux-vdso.so.1 => (0x00007fff23955000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8ab3338000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8ab3122000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8ab2f05000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8ab2b7b000) /lib64/ld-linux-x86-64.so.2 (0x00007f8ab35d9000)

Profile [VENETO] sabayonino
Avatar
Send message
Joined: 21 Jan 14
Posts: 12
Credit: 2,096,193
RAC: 123
Italy
Message 329 - Posted: 24 Jan 2014, 12:26:21 UTC
Last modified: 24 Jan 2014, 12:39:56 UTC

i think there's link problem to the dinamic linker in 64bit platform to run 32 bit binaries

in 64 bit platform , /lib is linked to /lib64 folder.

your excutable check all libraries in /lib and /lib64

you can try this :

cd /lib && sudo ln -s /lib64/ld-linux-x86-64.so.2

(file exists ?? )

hope fine.
____________
Powered by Gentoo Linux
Kernel : 4.4.26-gentoo
KDE 16.04.3

Simone [3dz2]
Send message
Joined: 18 Nov 13
Posts: 6
Credit: 279,326
RAC: 0
Italy
Message 330 - Posted: 24 Jan 2014, 21:49:50 UTC - in response to Message 329.

ls -lh /lib64/ totale 0 lrwxrwxrwx 1 root root 32 dic 30 2012 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.13.so


ls -lh /lib/ omissis lrwxrwxrwx 1 root root 25 dic 30 2012 ld-linux.so.2 -> i386-linux-gnu/ld-2.13.so omissis


Why should I put a link to x86_64 library in /lib ?
And in all cases, 2.13 glibc version is installed for both 32 and 64, while the 64bit executable needs 2.14 glibc.

Profile FrancescoAsnicar [SSC11]
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 14 Nov 13
Posts: 50
Credit: 6,656,949
RAC: 5,281
Italy
Message 331 - Posted: 25 Jan 2014, 9:04:36 UTC - in response to Message 330.

As I wrote on the BOINC @ TN thread on BOINC.Italy the 32 bit Linux executable was compiled on Ubuntu with kernel 3.2.0-56 and glib version 2.13, while the 64 bit was compiled on Ubuntu with kernel 3.2.0-23 and glib version 2.13..

I can't figure out why the 32 bit is resolved while the 64 bit still present the known issue related to the glib version.

Hope we can find out soon and solve this problem.
Thanks again for report here all the problems you guys found!

Profile valterc
Project administrator
Project tester
Send message
Joined: 30 Oct 13
Posts: 320
Credit: 16,287,174
RAC: 4,127
Italy
Message 332 - Posted: 25 Jan 2014, 11:15:40 UTC - in response to Message 331.
Last modified: 25 Jan 2014, 11:15:58 UTC

I duplicate here something I also wrote on the other forum:

Talking about the x64 version, by running objdump -T you may verify that the only module which needs GLIBC 2.14 is the memcpy function.

By browsing the web I saw a lot of discussions about this problem, see here as an example: http://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file. IMHO the easiest fix to try is to extract memcpy.o from the glibc library and link with it statically.

Profile [VENETO] sabayonino
Avatar
Send message
Joined: 21 Jan 14
Posts: 12
Credit: 2,096,193
RAC: 123
Italy
Message 333 - Posted: 25 Jan 2014, 15:37:30 UTC - in response to Message 331.
Last modified: 25 Jan 2014, 16:16:33 UTC

As I wrote on the BOINC @ TN thread on BOINC.Italy the 32 bit Linux executable was compiled on Ubuntu with kernel 3.2.0-56 and glib version 2.13, while the 64 bit was compiled on Ubuntu with kernel 3.2.0-23 and glib version 2.13..

I can't figure out why the 32 bit is resolved while the 64 bit still present the known issue related to the glib version.

Hope we can find out soon and solve this problem.
Thanks again for report here all the problems you guys found!


gcc version (or other compiler...) ?


@ valter : see this http://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html
memcpy seems to be pushed by gcc option

you could try to pass -fno-builtin-memcpy option to gcc comand line


[edit] memcpy function in C (Italian)

and
GCC docs
[...]-fno-builtin-function
Don't recognize built-in functions that do not begin with ‘__builtin_’ as prefix. See Other built-in functions provided by GCC, for details of the functions affected, including those which are not built-in functions when -ansi or -std options for strict ISO C conformance are used because they do not have an ISO standard meaning.

GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions which adjust the stack directly, and calls to memcpy may become inline copy loops. The resulting code is often both smaller and faster, but since the function calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior of the functions by linking with a different library. In addition, when a function is recognized as a built-in function, GCC may use information about that function to warn about problems with calls to that function, or to generate more efficient code, even if the resulting code still contains calls to that function. For example, warnings are given with -Wformat for bad calls to printf when printf is built in and strlen is known not to modify global memory.

With the -fno-builtin-function option only the built-in function function is disabled. function must not begin with ‘__builtin_’. If a function is named that is not built-in in this version of GCC, this option is ignored. There is no corresponding -fbuiltin-function option; if you wish to enable built-in functions selectively when using -fno-builtin or -ffreestanding, you may define macros such as:

#define abs(n) __builtin_abs ((n))
#define strcpy(d, s) __builtin_strcpy ((d), (s))
[...]



is memcpy needed ?
____________
Powered by Gentoo Linux
Kernel : 4.4.26-gentoo
KDE 16.04.3

Simone [3dz2]
Send message
Joined: 18 Nov 13
Posts: 6
Credit: 279,326
RAC: 0
Italy
Message 334 - Posted: 25 Jan 2014, 20:54:56 UTC - in response to Message 333.

The application is opensource, or, anyway, freely available? I can try to build it on my computer and send you the executable...

Profile valterc
Project administrator
Project tester
Send message
Joined: 30 Oct 13
Posts: 320
Credit: 16,287,174
RAC: 4,127
Italy
Message 335 - Posted: 27 Jan 2014, 10:34:36 UTC - in response to Message 334.

The application is opensource, or, anyway, freely available? I can try to build it on my computer and send you the executable...

The application will be probably released as 'open source' in the near future. By now I don't have access to the source code.


Post to thread

Message boards : Unix/Linux : glibc version problem


Main page · Your account · Message boards


Copyright © 2017 CNR-TN & UniTN