yi li wrote:
> On Thu, Feb 26, 2009 at 6:20 PM, Gilles Chanteperdrix
> <gilles.chanteperd...@xenomai.org> wrote:
>> -lpthread does need to be set in libpthread_rt_la_LDFLAGS, if you look
>> at libpthread_rt code (which you apparently do not want to dot), you
>> will see that it uses libpthread functions.
> Thanks for the detailed explanation. And I did read libpthread_rt code ;).
> However, my point is _not_ putting "-lpthread" before or after
> "libpthread_rt.a". My point is, is it reasonable to put "-lpthread" in
> the LDFLAGS of libpthread_rt.a?
For the third time, libpthread_rt.a uses libpthread, so it is not only
reasonable, but mandatory to put -lpthread in the LDFLAGS of
>> The issue you have has already been discussed on this list, and we
>> already know the correct workaround. The correct workaround is not to
>> link with -lpthread first. Linking with -lpthread first leads to broken
>> binaries, whose libpthread functions call libpthread_rt functions. The
>> correct workaround is to link your binary in two stages, or to forget
>> about FLAT and use FDPIC.
> In my option, a better workaround is to group the achieves, with
> "--start-group", "--end-group":
> bfin-uclinux-gcc -pipe -Wall -g -O2 -mcpu=bf527-0.1
> -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -Wl,-elf2flt -mcpu=bf527-0.1 -o
> cyclictest cyclictest-cyclictest.o -lrt -Wl,--start-group
> ../../skins/posix/.libs/libpthread_rt.a -lpthread -Wl,--end-group
No, for the third time, it does not work, when libpthread starts to use
libpthread_rt symbols, things are going wrong.
Xenomai-core mailing list