On Fri, 8 Feb 2002, Maxim Sobolev wrote:
> Terry Lambert wrote:
> >
> > Maxim Sobolev wrote:
> > > $ cc test.c -o test -lc -lc_r
> > >
> > > When either of -lc or -lc_r is omitted, or their order is reversed the
> > > problem disappears. The problem doesn't exist on 4-STABLE.
> > >
> > > Any ideas, comments and suggestions are welcome.
> >
> > Symbols are resolved from libraries in the order in which
> > they are specified to the linker.
> >
> > So the fix is obvious: specify them in the right order.
> >
> > Linux doesn't see this because libc_r is just there for
> > the reentrant calls, and their threading uses processes,
> > instead of a user space ("quantum conservation") scheduler.
>
> All not as easy as it seems to be. -lc could come not from the command
> line, but from one of the other libraries the binary being linked
> with. Therefore, in real life resolving this problem could be a little
> more tricky, especially with large applications (e.g. Evolution), that
> uses code from 30+ shared libraries. I think that ld(1) should be
> smart enough to reorder libc/libc_r so that libc_r is always linked
> before libc.
As you've found out, you have to link libc_r first. You shouldn't
even specify -lc because the linker will automatically pull that
in correctly. I don't think we should even try to support
linking libc before libc_r or libpthread. The linker is working
the way it is suppose to. Get the Evolution guys to fix the way
it is built...
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
