I'm trying to understand the following here
I have a simple test program that calls memcpy/malloc/printf
int main(int argc, char **argv) { char * p = malloc(10); memcpy(p,"Hello",6); printf("%s\n", p); }
When looking at the symbol list why are the following routines undefined? And why is it referncing GLIBC_2.2.5?
$ nm /tmp/f |grep ' U ' U __libc_start_main@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.2.5 U printf@@GLIBC_2.2.5
$ rpm -qa |grep -i glibc glibc-2.3.4-2.41 glibc-common-2.3.4-2.41 glibc-2.3.4-2.41
I really can't find an explination for this and was wondering if someone could clear it up. Thanks.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
I'm trying to understand the following here
I have a simple test program that calls memcpy/malloc/printf
int main(int argc, char **argv) { char * p = malloc(10); memcpy(p,"Hello",6); printf("%s\n", p); }
When looking at the symbol list why are the following routines undefined? And why is it referncing GLIBC_2.2.5?
$ nm /tmp/f |grep ' U ' U __libc_start_main@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.2.5 U printf@@GLIBC_2.2.5
$ rpm -qa |grep -i glibc glibc-2.3.4-2.41 glibc-common-2.3.4-2.41 glibc-2.3.4-2.41
I really can't find an explination for this and was wondering if someone could clear it up.
libc has "versioned symbols", and you're linking against the default implementations of each of the three symbols, as defined in the version of libc you built against (the "@@" notation means the default version of a versioned symbol).
For detailed information on this, see: http://people.redhat.com/drepper/dsohowto.pdf and for the most detail, see: http://people.redhat.com/drepper/symbol-versioning
Hope this helps Dave
Dave so essentially @@GLIBC_2.2.5 is the symbol version set this release is based on? Not necessarily having anything to do with the underlying RPM package version? This is what I'm getting from your explanation.
One question I'm still uncertain about is why do these symbols still show up as undefined?
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list-bounces@redhat.com] On Behalf Of David Malcolm Sent: Friday, September 18, 2009 10:54 AM To: Development discussions related to Fedora Subject: Re: GNU libc confusion with symbols undefined.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
I'm trying to understand the following here
I have a simple test program that calls memcpy/malloc/printf
int main(int argc, char **argv) { char * p = malloc(10); memcpy(p,"Hello",6); printf("%s\n", p); }
When looking at the symbol list why are the following routines undefined? And why is it referncing GLIBC_2.2.5?
$ nm /tmp/f |grep ' U ' U __libc_start_main@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.2.5 U printf@@GLIBC_2.2.5
$ rpm -qa |grep -i glibc glibc-2.3.4-2.41 glibc-common-2.3.4-2.41 glibc-2.3.4-2.41
I really can't find an explination for this and was wondering if someone could clear it up.
libc has "versioned symbols", and you're linking against the default implementations of each of the three symbols, as defined in the version of libc you built against (the "@@" notation means the default version of a versioned symbol).
For detailed information on this, see: http://people.redhat.com/drepper/dsohowto.pdf and for the most detail, see: http://people.redhat.com/drepper/symbol-versioning
Hope this helps Dave
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Brown, Rodrick wrote:
Dave so essentially @@GLIBC_2.2.5 is the symbol version set this release is based on? Not necessarily having anything to do with the underlying RPM package version? This is what I'm getting from your explanation.
Those symbols have not changed since version 2.2.5, so the symbol version is still 2.2.5.
Kevin Kofler
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
I'm trying to understand the following here
I have a simple test program that calls memcpy/malloc/printf
int main(int argc, char **argv) { char * p = malloc(10); memcpy(p,"Hello",6); printf("%s\n", p); }
When looking at the symbol list why are the following routines undefined? And why is it referncing GLIBC_2.2.5?
$ nm /tmp/f |grep ' U ' U __libc_start_main@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.2.5 U printf@@GLIBC_2.2.5
They're "undefined" in your binary because your binary does not define them. It references them, and some other library you're linked against provides them.
- ajax
Thanks!!
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list-bounces@redhat.com] On Behalf Of Adam Jackson Sent: Friday, September 18, 2009 11:08 AM To: Development discussions related to Fedora Subject: Re: GNU libc confusion with symbols undefined.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
I'm trying to understand the following here
I have a simple test program that calls memcpy/malloc/printf
int main(int argc, char **argv) { char * p = malloc(10); memcpy(p,"Hello",6); printf("%s\n", p); }
When looking at the symbol list why are the following routines undefined? And why is it referncing GLIBC_2.2.5?
$ nm /tmp/f |grep ' U ' U __libc_start_main@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.2.5 U printf@@GLIBC_2.2.5
They're "undefined" in your binary because your binary does not define them. It references them, and some other library you're linked against provides them.
- ajax