This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: linker errors when compiling and linking with a new glibc
- From: Ryan Arnold <ryan dot arnold at gmail dot com>
- To: Daniel De La Zerda <danieldelazerda at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Wed, 18 Mar 2009 11:51:47 -0500
- Subject: Re: linker errors when compiling and linking with a new glibc
- References: <684720.61839.qm@web63201.mail.re1.yahoo.com>
On Mon, Mar 16, 2009 at 6:16 PM, Daniel De La Zerda
<ddelazerda007@yahoo.com> wrote:
>
> I'm new to this so please be patient. I added a function pthread_foo_init() in foo.c with it's respective foo.h under the nptl directory. Then edited the Makefile inside the same directory to reflect these changes. After this I ran make and my new glibc built with no errors at all. I have the libc.so under the main directory of the glibc tree and libpthread.so under nptl. If I do a "nm libpthread.so | grep pthread_mutex_init" I see that the pthread_mutex_init symbol is global and not static - indicated by the "T" right before the function name. When I do "nm libpthread.so | grep pthread_foo_init" I see that it has a "t", and if I'm not mistaken, this means that it is local and static and that it cannot be seen by the outside world. Hence that's why I think I get linker errors when I try to compile a test program that uses my "pthread_foo_init()" saying that I have an "undefined reference to `pthread_foo_init`". Does anyone have any idea how I can solve
> Âthis problem?
Daniel,
Did you add pthread_foo_init to the export list in the nptl Versions file?
If not, then you won't get an external symbol for it.
Regards,
Ryan S. Arnold