sigprocmask testing program failed with static linking

[Jian Peng]

Thank you, Austin. Since I am not familiar with internal design of libc and libpthread, I am afraid of messing it up by reimplementing those pieces.

Looking forward to testing your patch.

Jian

On Apr 21, 2011, at 6:23 PM, "Austin Foxley" <austinf at cetoncorp.com> wrote:

> On 03/27/2011 12:27 AM, Jian Peng wrote:
>> This is one of many potential static linking problems in uClibc. Last time, I reported a bug on sigaction and submitted a patch, but similar multiple definition error could happen to any function that was defined as GLOBAL in both libc.a and libpthread.a while certain runtime supporting function from libc, like abort(), also call it.
>> 
>> For example, sigprocmask-test.c is a simple testing program and
>> 
>> $ gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread
>> 
>> Since sigprocmask is GLOBAL in both libc.a and libpthread.a, sigprocmask called in main function will pull in pt-sigprocmask.os from libpthread.a, but later, another sigprocmask called in abort (part of libc) will pull in sigprocmask.os from libc.a and leads to multiple definition error.
>> 
>> To fix it, sigprocmask has to be defined as weak symbol. The same solution could be applied to other functions in libc/sysdeps/linux/common that will be called in both main and runtime supporting function in libc. I will identify them and post patch later.
>> 
>> Here is my patch to fix sigprocmask, and it was tested on gcc-4.5.2 based toolchain on MIPS.
> 
> 
> I've also ran into this problem recently but I fixed it by simply 
> removing the libpthread version entirely and forcing the calls to go 
> through libc. The calls I had trouble with were sigaction, sigprocmask, 
> and sigfillset.
> 
> I think this is what Peter meant was his preferred solution in the reply 
> to your earlier email?
> 
> Peter can you comment? I can put together a patch of what I've been 
> using and push it to future if that is what you meant.
> 
> -Austin
>