Date: Sun, 31 Aug 2003 23:17:38 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Scott Long <scottl@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h Message-ID: <1062386257.42216.21.camel@shumai.marcuscom.com> In-Reply-To: <3F52B5CE.8040905@freebsd.org> References: <Pine.GSO.4.10.10308312240001.15178-100000@pcnet5.pcnet.com> <3F52B5CE.8040905@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-I7ZkweMjL8LRCYNb41UH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Sun, 2003-08-31 at 22:58, Scott Long wrote:
> Daniel Eischen wrote:
> > On Sun, 31 Aug 2003, Joe Marcus Clarke wrote:
> >=20
> >=20
> >>On Sun, 2003-08-31 at 22:05, Scott Long wrote:
> >>
> >>>Daniel Eischen wrote:
> >>>
> >>>>deischen 2003/08/31 15:38:52 PDT
> >>>>
> >>>> FreeBSD src repository
> >>>>
> >>>> Modified files:
> >>>> contrib/gcc/config freebsd-spec.h=20
> >>>> Log:
> >>>> Remove -pthread as a compiler option. It was deprecated 2.5 years
> >>>> ago, but not removed.
> >>>> =20
> >>>> No reply from: threads, kan, obrien
> >>>> =20
> >>>> Revision Changes Path
> >>>> 1.10 +2 -38 src/contrib/gcc/config/freebsd-spec.h
> >>>>
> >>>
> >>>What is the consequence of this on ports/? I'm very much in
> >>>favor of this change, but I'm wondering if more safety belts are
> >>>needed. Also, are there any consequences on the doc/ and www/
> >>>areas?
> >=20
> >=20
> > I don't know, but it hasn't been -pthread in current in over
> > 2.5 years. Yes, -pthread was there as a bandaid, but it wasn't
> > _the_ way to build threaded applications under -current. So,
> > -pthread _was_ the safety belt.
> >=20
> >=20
> >>I have a feeling we will see an increase of port build errors on
> >>-CURRENT. This may not be a bad thing, though. It will show us which
> >>ports are not using ${PTHREAD_LIBS} correctly.
> >=20
> >=20
> > I agree. This is only the first step, though. Once ports
> > get through this, there may be another hurdle once libkse
> > becomes libpthread again. Autoconf may autodetect the presence
> > of a libpthread and link to it, in conjunction with linking
> > to ${PTHREAD_LIBS} being picked up somewhere else in the
> > port. Just try building XFree86-4 or kde with libpthread
> > (libkse installed as libpthread) and ${PTHREAD_LIBS} set
> > to libc_r. It links to both libraries.
> >=20
>=20
> This opens up very important questions. How do we smoothly make
> the transition?
What GNOME ports are doing is replacing -lpthread with ${PTHREAD_LIBS}
wherever we see it. This is done via the gnomehack meta-component.=20
There is also a proposal to make a general pthread hack in ports/55683.
> What is the appropriate threading library for each
> platform?
Once we decide on this, it should be easy to adjust bsd.port.mk to set
PTHREAD_LIBS accordingly for each platform.
> Should 'libpthread' be a symlink, or should a library be
> renamed?
I don't think you have to do either. It should be easy enough to have
${PTHREAD_LIBS} be set to a reasonable value on each platform, plus have
users override that if they desire.
> How do we answer these last two questions in a consistent
> fashion?
I think the main platform developers need to answer the preferred thread
implementation question, then it needs to be done in bsd.port.mk.
Joe
> Where does libmap fit in?
>=20
> Scott
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-I7ZkweMjL8LRCYNb41UH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQA/UrpRb2iPiv4Uz4cRArKOAKCmuXF+tcXdeKj8Fu8VFfZ8eh7wIACfcOwR
+mr/Misog/aRI89cHZQZLTU=
=xL28
-----END PGP SIGNATURE-----
--=-I7ZkweMjL8LRCYNb41UH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1062386257.42216.21.camel>