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?
>> 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
Yi, the point is about our use of the --wrap linker directive for linking POSIX
apps. If we go for the start/end group scheme, then we will end up having
libpthread wrongly use our wrapped libpthread calls from libpthread_rt, which is
going to break the application badly. This is the other way around: our wrappers
may want to use libpthread.
We just cannot let the linker pick whatever symbol it sees fit to resolve the
references, it is not a dependency order issue that start/end group would indeed
solve. When using a static link format, we have to make sure to resolve the
references the applications makes to libpthread_rt first, then, and only after
that, finalize the link with libpthread, because both the application and
libpthread_rt have dependencies on libpthread.
This is why we are talking about "two-phase" link for static mode. In fact,
fixing the issue your reported would require to implement two-phase link
conditionally in our Makefiles producing POSIX binaries, to be used when FLAT
format is wanted. This is doable, but requires a bit more work than just
reordering or removing dependencies on libpthread.
Xenomai-core mailing list