Date: 13 Mar 2003 18:15:37 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: hackers@FreeBSD.ORG Subject: Re: Question on gcc linker and -pthread Message-ID: <1047597337.84063.43.camel@gyros> In-Reply-To: <20030313230538.GA58315@ns1.xcllnt.net> References: <1047586732.84063.10.camel@gyros> <20030313230538.GA58315@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-AvF7j8uAzTab7OYaPJgx
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Thu, 2003-03-13 at 18:05, Marcel Moolenaar wrote:
> On Thu, Mar 13, 2003 at 03:18:52PM -0500, Joe Marcus Clarke wrote:
> > I've noticed something I think is strange with gcc, the -shared flag,
> > and -pthread on -STABLE. I'm hoping someone can enlighten me as to why
> > this happens or if it's a bug. If I compile something with the
> > following command, I do not see libc_r.so linked in the resulting
> > object:
> >=20
> > cc -shared -pthread -o xxx.so xxx.c
> >=20
> > However, if I replace -pthread with -lc_r, it works. Also, if I change
> > the command to:
> >=20
> > cc -Wl,-shared -pthread -o xxx.so xxx.c
> >=20
> > I also see libc_r.so linked in. Is this expected behavior? libtool
> > seems to like the former -shared syntax which is causing some problems
> > with some GTK themes. Thanks.
>=20
> The -shared option tells the compiler driver that you're trying to
> create a shared object. In that case -lc_r is not added to the link
> line. Adding -lc_r explicitly is dangerous, because now the linker
> will construct a shared object that has code linked in from an
> archive library that has not been compiled with PIC. Consequently,
> some architectures (eg ia64) may barf when you try to link against
> this shared object because it may contain invalid relocations.
>=20
> 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. =20
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? Since ia64 is
a -CURRENT only architecture, your explanation makes me think using
-lc_r explicitly in -CURRENT is still a bad idea.
Joe
>=20
> I don't think there's a bug.
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-AvF7j8uAzTab7OYaPJgx
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQA+cREZb2iPiv4Uz4cRAnrhAKCPw9rlrNxrwqeR5goTHPi7XPTAZACfYtM5
NBafwYmV7++y9d7RuX92rcY=
=44zu
-----END PGP SIGNATURE-----
--=-AvF7j8uAzTab7OYaPJgx--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1047597337.84063.43.camel>