GLIBC_2.14 memcpy

[Ian Douglas]

Hi all

So I write my first hello world program, and it runs fine. Upload to the server, but it does not run there.

./Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./Hello1)

Dev box is Gentoo linux, server is CentOS 6.2

Google shows many C programmers complaining about similar issue.

Some analysis shows the problem to be memcpy wanting GLIBC_2.14 while everything else is happy with GLIBC_2.25.

I can't find anything relevant in this newsgroup (surprising!), or on AdaCore's site (program was built with GPS), so I was wondering if anyone has a workaround ... the C people add a line to force the compiler to use a more recent version of memcpy, as per

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

While I am horrified at the necessity of doing something like that (especially for a simple Hello World), how would I do this in Ada / Gnat?

(A way to do it globally for C is here:
http://rjpower9000.wordpress.com/2012/04/09/fun-with-shared-libraries-version-glibc_2-14-not-found/)

Thanks, Ian

[Tero Koskinen]

22.4.2014 16:28, Ian Douglas wrote:
> Hi all
>
> So I write my first hello world program, and it runs fine. Upload to
> the server, but it does not run there.
>
> ./Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required
> by ./Hello1)
>
> Dev box is Gentoo linux, server is CentOS 6.2

This error message tells that the program is compiled against different
glibc version. The correct solution is to compile the program using
same glibc version in both environments (dev box / server).

For example, you can setup virtual CentOS 6.2 build machine for
compilation purposes only and then deploy the binary from there to your
server.

> Some analysis shows the problem to be memcpy wanting GLIBC_2.14
> while everything else is happy with GLIBC_2.25.
>
> I can't find anything relevant in this newsgroup (surprising!), or
> on AdaCore's site (program was built with GPS), so I was wondering
> if anyone has a workaround ... the C people add a line to force the
> compiler to use a more recent version of memcpy, as per
>
> __asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
>
> While I am horrified at the necessity of doing something like that
> (especially for a simple Hello World), how would I do this in Ada /
> Gnat?

You should not try to use force and make your binary application to use
different version of the glibc.

It is likely that the binary interface of the glibc has changed between
two versions and the program compiled against one version behaves
differently if used with another version. Like imagine, if the order
of some function arguments have changed and your program does Copy (Src,
Dest) instead of Copy (Dest, Src). (Probably not, but you get the idea.)

> Thanks, Ian
>

Yours,
Tero

[Ian Douglas]

hi All

On Tuesday, 22 April 2014 18:54:36 UTC+2, Tero Koskinen wrote:
>
> This error message tells that the program is compiled against different
> glibc version. The correct solution is to compile the program using
> same glibc version in both environments (dev box / server).

Yes, I tried that approach but could not update the glibc on the server (no later version available, it seems) and downgrading what's on my dev box is asking for trouble..

>
> For example, you can setup virtual CentOS 6.2 build machine for
> compilation purposes only and then deploy the binary from there to your
> server.

Ah. Was almost going to get a complete separate box to solve the problem, but that raised all sorts of workflow issues.

Have no experience with virtual machines so have another steep learning curve in front of me.

I was reluctant to follow these sort of paths because of the necessity of then keeping the dev and live environment in sync ... I was hoping for some sort of 'if it compiles on THIS x86_64 then it will certainly run on THAT x86_64 box' but I guess things like linked libraries make that impossible, and sticking the library into the executable will make it huge.

> It is likely that the binary interface of the glibc has changed between
> two versions and the program compiled against one version behaves
> differently if used with another version. Like imagine, if the order
> of some function arguments have changed and your program does Copy (Src,
> Dest) instead of Copy (Dest, Src). (Probably not, but you get the idea.)

Apparently the root cause goes back to something someone on the Linux kernel did which has major downstream knockon effects (and lots of unhappy programmers wasting thousands of hours trying to find out why things would just not work when they did before). I had hoped the issue would have been sorted by now. I wonder if upgrading to CentOs 6.4 would solve it? ... the server is a 'cloud' type server which is also a whole new environment for me.

Thanks for your help :-)

cheers, Ian

[Jeffrey Carter]

On 04/22/2014 12:41 PM, Ian Douglas wrote:
>
> 'if it compiles on THIS x86_64 then it will certainly run on THAT
> x86_64 box'

While that might not work, it is generally true that if it compiles on THIS box
then it will certainly build on THAT box. So moving the source from the dev box
to the target box and building on the target box will work, and obviate any
perceived disadvantages of maintaining a dev system the same as the target
(presuming you can spare the processing power for the build once in a while).

--
Jeff Carter
"Insufficient laughter--that's grounds for divorce."
Play It Again, Sam
126

[Stephen Leake]

Ian Douglas <i...@vionia.com> writes:

> So I write my first hello world program, and it runs fine. Upload to
> the server, but it does not run there.
>
> ./Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required
> by ./Hello1)

Use static rather than dynamic linking.

--
-- Stephe

[an...@att.net]

Why not use the HI-E (high integrity version) of "System-Memory_Copy"
package which routines can be written Ada. Instead of using 'libC'

gnat compile s-memcop

then add "-largs s-memcop.o" at the end of gnat command line

gnat make hello.adb -largs s-memcop.o

In <d740404d-05f1-4b4b...@googlegroups.com>, Ian Douglas <i...@vionia.com> writes:
>Hi all
>

>So I write my first hello world program, and it runs fine. Upload to the se=

>rver, but it does not run there.
>

>../Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./H=

>ello1)
>
>Dev box is Gentoo linux, server is CentOS 6.2
>
>Google shows many C programmers complaining about similar issue.
>

>Some analysis shows the problem to be memcpy wanting GLIBC_2.14 while every=

>thing else is happy with GLIBC_2.25.
>

>I can't find anything relevant in this newsgroup (surprising!), or on AdaC=
>ore's site (program was built with GPS), so I was wondering if anyone has a=
> workaround ... the C people add a line to force the compiler to use a more=
> recent version of memcpy, as per=20
>
>__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
>
>While I am horrified at the necessity of doing something like that (especia=

>lly for a simple Hello World), how would I do this in Ada / Gnat?
>

>(A way to do it globally for C is here:=20
>http://rjpower9000.wordpress.com/2012/04/09/fun-with-shared-libraries-versi=
>on-glibc_2-14-not-found/)
>
>Thanks, Ian

[G.B.]

With glibc, static linking may work only to some extent.
It may work in this case.
IIRC, some networking routines will still be linked at run time.

Similarly, I'd prefer not to have linked libssl1.0.1 statically. ;-)

[Ian Douglas]

On Wednesday, 23 April 2014 09:47:56 UTC+2, Stephen Leake wrote:
>
>
> Use static rather than dynamic linking.

I thought I was .... but possibly am not.

Am using GPS, running the build via the GUI. Only 'static' option I see is on the Project -> Edit Project Properties -> Library where I selected 'Static' but nothing else on that tab is filled in ... should I add Glibc or somesuch there?

If it helps the executable size is over 500 KB. But apparently that is par for the course for beginners :-)

From the .gpr file:

package Compiler is
for Default_Switches ("ada") use ("-O2", "-gnat12", "-gnato", "-fstack-check", "-gnatE", "-gnatyde");
end Compiler;

package Linker is
for Default_Switches ("ada") use ("-Wl,--gc-sections");
end Linker;

for Source_Files use ("Hello1.adb");

package Builder is
for Default_Switches ("ada") use ("-s");
end Builder;

thanks, Ian

[Ian Douglas]

hi All

On Wednesday, 23 April 2014 09:53:00 UTC+2, an...@att.net wrote:
> Why not use the HI-E (high integrity version) of "System-Memory_Copy"
>
> package which routines can be written Ada. Instead of using 'libC'
>
> gnat compile s-memcop
>
> then add "-largs s-memcop.o" at the end of gnat command line
>
> gnat make hello.adb -largs s-memcop.o

Thanks for the suggestion. Results below.

~/1web/adatest1 $ gnat compile s-memcop
gcc -gnatpg -c -I./ -I- /usr/gnat/lib/gcc/x86_64-pc-linux-gnu/4.7.4/adainclude/s-memcop.ads
~/1web/adatest1 $ ll
total 564
-rwxr-xr-x 1 ian ian 547443 Apr 21 22:20 Hello1
-rw-r--r-- 1 ian ian 172 Apr 21 22:18 Hello1.adb
-rw-r--r-- 1 ian ian 1574 Apr 22 14:25 Hello1.ali
-rw-r--r-- 1 ian ian 1824 Apr 22 14:25 Hello1.o
-rw-r--r-- 1 ian ian 695 Apr 22 14:25 hello.gpr
-rw-r--r-- 1 ian ian 783 Apr 23 20:32 s-memcop.ali
-rw-r--r-- 1 ian ian 1004 Apr 23 20:32 s-memcop.o
~/1web/adatest1 $ gnat make Hello1.adb -largs s-memcop.o
gnatbind -x Hello1.ali
gnatlink Hello1.ali s-memcop.o
~/1web/adatest1 $ ll
total 564
-rwxr-xr-x 1 ian ian 547654 Apr 23 20:32 Hello1
-rw-r--r-- 1 ian ian 172 Apr 21 22:18 Hello1.adb
-rw-r--r-- 1 ian ian 1574 Apr 22 14:25 Hello1.ali
-rw-r--r-- 1 ian ian 1824 Apr 22 14:25 Hello1.o
-rw-r--r-- 1 ian ian 695 Apr 22 14:25 hello.gpr
-rw-r--r-- 1 ian ian 783 Apr 23 20:32 s-memcop.ali
-rw-r--r-- 1 ian ian 1004 Apr 23 20:32 s-memcop.o
~/1web/adatest1 $ ./Hello1
Hello, cruel world!

I am an Ada program with package use.

===============

Upload to server, SSH in and make executable.

[root@xaxint web]# ll
total 560
-rw-r--r-- 1 web1 client1 547654 Apr 23 20:33 Hello1
-rwxr-xr-- 1 web1 client1 7358 Apr 15 15:28 favicon.ico
-rwxr-xr-- 1 web1 client1 1861 Apr 15 15:28 index.html
-rwxr-xr-- 1 web1 client1 14 Apr 15 15:28 robots.txt
drwxr-xr-x 2 root root 4096 Apr 17 00:30 stats
[root@xaxint web]# chmod 744 Hello1
[root@xaxint web]# ./Hello1
./Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./Hello1)
[root@xaxint web]#

=============================

So end up with same issue....

thanks, Ian

[an...@att.net]

A simple System.Memory_Copy package

Compile the following package in a local directory using

gnat compile -a s-memcop.adb

then compile your program

gnat make hello -largs s-memcop.o

"-largs s-memcop.o" causes the linker to use the new version
instead of the standard library version. Note: The "-largs" must
be lower case.


-- File: s-memcop.ads

package System.Memory_Copy is
pragma Preelaborate ;

type Memory_Range is mod Memory_Size ;

procedure Memcpy ( Target_Address : in Address ;
Source_Address : in Address ;
Count : in Memory_Range ) ;
pragma Export ( C, Memcpy, "memcpy" ) ;

end System.Memory_Copy ;


-- File: s-memcop.adb

pragma Style_Checks (OFF); -- removes warning about souce
-- code format

pragma Suppress ( All_Checks ) ; -- removes all run-time checks
-- for this low-level package

with Interfaces ;

package body System.Memory_Copy is

procedure Memcpy ( Target_Address : in Address ;
Source_Address : in Address ;
Count : in Memory_Range ) is

use Interfaces ;

type Storage_Array is array ( 0 .. Count ) of Unsigned_8 ;

Target : Storage_Array ;
for Target ' Address use Target_Address ;

Source : Storage_Array ;
for Source ' Address use Source_Address ;

begin -- Memcpy
for Index in 0 .. Count loop
Target ( Index ) := Source ( Index ) ;
end loop ;
end Memcpy ;

end System.Memory_Copy ;

>../Hello1: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./Hello1)

[Ian Douglas]

On Thursday, 24 April 2014 11:56:15 UTC+2, an...@att.net wrote:
> A simple System.Memory_Copy package

Thanks, have followed your code and confirm that it works both 
locally and on the server.

The other thing is that the filesize dropped from 547654 to 343340 
which is better but still much more than I would like :-)

I did try using GNAT.IO first instead of ADA IO but that didn't work 
either.

Thanks again :)

cheers, Ian

[an...@att.net]

Your Welcome!

The reduction in "file size" due to the fact that the linker is
only adding the new "memcpy" function instead of adding the
complete GLIBC library. Now, "GNAT Ada" uses only a small number
of routines that are contained in the GLIBC library so it is easier
to rewrite the routines when they are needed instead of trying to
use the complete standard library.

Pro: 1. Smaller footprint, reduction of dead code.
2. Easy to compile for either 32 or 64 bit mode.
3. Easy to compile for different operating environments.

Con: Code may not be at maximum optimization unless code is
written using "System.Machine_Code".


Note: For a smaller footprint, and a faster code you could
rewrite the function "Memcpy" using System.Machine_Code
package. The footprint for the machine code is round 16
instructions while the Ada optimization code version is
around 21 instructions. So, unless the increase in speed
is paramount or memory is limited the use of machine code
may not be worth the additional work.

In <8d93b0b8-4cfb-43f9...@googlegroups.com>, Ian Douglas <i...@vionia.com> writes:
>On Thursday, 24 April 2014 11:56:15 UTC+2, an...@att.net wrote:
>> A simple System.Memory_Copy package
>

>Thanks, have followed your code and confirm that it works both=A0

>locally and on the server.
>

>The other thing is that the filesize dropped from 547654 to 343340=A0

>which is better but still much more than I would like :-)
>

>I did try using GNAT.IO first instead of ADA IO but that didn't work=A0