On Sun, Oct 2, 2016 at 12:45 PM, Samuel Thibault
<samuel.thiba...@gnu.org> wrote:
> David Michael, on Sun 02 Oct 2016 12:18:50 -0700, wrote:
>> On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault <samuel.thiba...@gnu.org> 
>> wrote:
>> > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
>> >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking
>> >> (namely ext2fs.static) from missing pthread_setcancelstate.
>> >
>> > Ah? I don't understand how: this commit only makes libpthread use its
>> > own internal __pthread_setcancelstate symbol. A pthread_setcancelstate
>> > alias is still defined from pthread/pt-setcancelstate.c, how is it that
>> > you don't get it?
>>
>> The following is the actual error when using that commit.  It looks
>> like pthread_setcancelstate is defined in libpthread2.a, and the
>> linking command includes -lpthread, which includes -lpthread2.
>> Changing error.c and pthread-functions.h doesn't seem correct since
>> there are many other instances of that throughout glibc.
>
> Actually it *is* correct :)
> When an application uses error(), it still shouldn't get the
> pthread_setcancelstate symbol, and thus error.c should be using
> __pthread_setcancelstate, to avoid pulling pthread_setcancelstate.
>
> That being said, glibc 2.22 didn't fix that yet, that'll be for glibc
> 2.23 and later, better not try to backport this which might pose other
> troubles.
>
>> /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error':
>> (.text+0x26f): undefined reference to `pthread_setcancelstate'
>
> So I'm surprised by this. Is -lpthread properly *after* libcrt.a?

Well, -lcrt doesn't appear explicitly in the command-line for either
exec.static or ext2fs.static.  The builds actually succeed if I add
either -lc or -lcrt (or their full paths) before or after -lpthread,
e.g. by `echo exec.static: -lc >> exec/Makefile`, so I'm not sure what
is going on yet.

Thanks.

David

Reply via email to