On Thu, Mar 13, 2003 at 06:15:37PM -0500, Joe Marcus Clarke wrote:
> > Using -Wl,-shared tricks the compiler driver in thinking you are
> > creating an executable. It will therefore make sure dependencies
> > are correct by adding -lc_r on the link line. You tell the linker
> > however that you're creating a shared object, but now it also has
> > -lc_r explicitly. Again, this can result in a bad shared object.
>
> Thanks for the explanation. After I sent the email, I looked at the
> FreeBSD spec header for GCC. I saw that -lc_r is only passed to the
> linker if -shared is not specified.
>
> I'm still a bit confused because for ports, ${PTHREAD_LIBS} is set to
> -lc_r in -CURRENT which will result in shared objects having a libc_r.so
> link. However, in -STABLE, ${PTHREAD_LIBS} is set to -pthread. If one
> specifies -pthread in -CURRENT, they will get the -STABLE linking
> behavior. So, all -CURRENT users won't see the undefined symbol problem
> I'm seeing in -STABLE. Is this inconsistency by design?
That's a good question. I tend to think it's not by design, as very
little really is :-)
> Since ia64 is
> a -CURRENT only architecture, your explanation makes me think using
> -lc_r explicitly in -CURRENT is still a bad idea.
Yes. We have the same problem with libobjc.a that's being linked into
a shared object (ports/lang/gnustep-base). The problem is not easily
resolved, although it's easy to come up with possible solutions.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
