cvs commit: src/contrib/gcc/config freebsd-spec.h

[Daniel Eischen]

On Sun, 31 Aug 2003, David O'Brien wrote:

> On Mon, Sep 01, 2003 at 01:22:47AM -0400, Daniel Eischen wrote:
> > On Sun, 31 Aug 2003, David O'Brien wrote:
> > 
> > > On Sun, Aug 31, 2003 at 03:38:52PM -0700, Daniel Eischen wrote:
> > > > deischen    2003/08/31 15:38:52 PDT
> > > > 
> > > >   FreeBSD src repository
> > > > 
> > > >   Modified files:
> > > >     contrib/gcc/config   freebsd-spec.h 
> > > >   Log:
> > > >   Remove -pthread as a compiler option.  It was deprecated 2.5 years
> > > >   ago, but not removed.
> > > >   
> > > >   No reply from:  threads, kan, obrien
> > > 
> > > Please back this out.
> > 
> > Unlike the patch I sent to you, this doesn't take anything
> > off a vendor branch; I realized it wasn't necessary.
> 
> If we are going to loose "-pthread" for 5.x, your patch is still wrong --
> it creates a 35-line diff to the FSF sources that is unnecessary and
> makes maintenance of GCC that much harder.  I just *know* that CVS will
> barf hard on the next GCC import.
> 
> What you want to do can be done with only a 3-line diff.  Given the extra
> maintenance issue that GCC is (and I've never seen you participate on the
> GCC mailing lists), it would have been nicer if you had sent a reminder
> about your patch and made it perfectly clear it wasn't an FYI, but an "I
> intend to commit this".

Well, that was the intent of the first email.  gcc does not
have a MAINTAINER any longer, and I didn't get any reply from
you or kan...

> > The first part of the patch I sent (gcc/config.gcc) should be
> > forwarded back to FSF and we can bring it back in from a future
> > import.  I did not commit that part of the patch.  I only committed
> > to freebsd-spec.h which I can see from the logs has been modified
> > at other times without being imported from GCC.
> 
> It still needs to be maintainer WRT the FSF GCC sources so that required
> changes can be brought into our tree.  The person that committed that
> part of code into the FSF GCC tree is proud of it and is our greatest
> ally of those active in GCC development.  That alone means we should have

I am not dissing any part of that code.  I simply wanted to
remove -pthread and saw that others had made changes in
the same file (plus no response from you or kan).

> worked with issue out with him.  More indications you probably don't know
> the history of FreeBSD GCC development and should step more carefully
> when committing in src/contrib/gcc.
> 
> 
> > > remove this like this w/o coordinating with the code in the FSF repo.
> > 
> > Sure, we can coordinate, but I don't see a reason to hold
> > this up when all we are changing is a file that is already
> > off the vendor branch.  Coordinate all you want, but let's
> > move on :-)
> 
> I hope my explanations above show why we shouldn't go quickly in our own
> direction on this saying "damned the FSF code".  On a vendor branch or
> not, gross changes to vendor sources makes it harder to import the next
> vendor version, and surely you want GCC 3.3.2 in FreeBSD when it comes
> out.

No, you showed me that when I want your attention, all I have
to do is commit to contrib/gcc.  It seems to be a quicker way
to get a response :-) :-)

>  
> > > {Net,Open}BSD and Linux all accept the "-pthread" option.  By removing
> > > support for it we are the odd man out on accepted GCC options.  You also
> > 
> > {Net,Open}BSD have it because they had the same problem with
> > libc_r (it couldn't be linked with libc).  Since when did Linux
> > get this hack and why?
> 
> I don't know when Linux get it, go read the FSF GCC CVS logs.  Here is
> what is in /usr/src/contrib/gcc/config/linux.h:
> 
>     #define LIB_SPEC \
>       "%{pthread:-lpthread} \
> 
> with Linux on Sparc and PowerPC/RS6000 also adding:
> 
>     #define CPP_SUBTARGET_SPEC \
>       ...
>       %{pthread:-D_REENTRANT}
> 
> The GCC documentation also document that RS6000/PowerPC targets will all
> accept "-pthread".
> http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/RS-6000-and-PowerPC-Options.html#RS%2f6000%20and%20PowerPC%20Options
> 
>  
> > Why do we have to get stuck with this option and lumped-in
> > with {Net,Open}BSD and Linux?  Why are not other OSes also in
> > the same lump?
> 
> Because people write Makefile's targeting multiple OS's.

Well, we have multiple thread libraries and -pthread doesn't
allow for that.  Having it just causes more problems than
not having it.

> > > break Makefile compatibility with FreeBSD 4.x.
> > 
> > How?  libgcc?  It doesn't need -lc_r or -pthread since it
> > uses weak symbols.
> 
> For one, don't forget people use the GCC ports and the stock sources from
> the FSF -- we don't need the system compiler to be the old man out.  If
> you really want to de-support "-pthread" there are two ways to go about
> it.  (1) starting with some GCC version, (2) starting with targeting a
> particular FreeBSD version.  For instance we could either say that GCC
> 3.4 does not accept "-pthread" for any FreeBSD target.  Or we could say
> that GCC targeting RELENG_5 does not accept "-pthread".  It should be
> clear which is being chosen and the repercussions.

RELENG_5 should not support it.  We need to get rid of
it ASAP so we can work on getting our ports free of it
and making them work with other thread libraries.

How do we accomplish this quickly?

> Second, are you saying that in RELENG_4, I don't need to link with libc_r
> and not libc?  That is what "-pthread" does for me in RELENG_4.

Actually, I was thinking about RELENG_5 Makefile compatabilitly
with regard to building libgcc, but now that you bring
the subject up...

Can't you use the same approach in RELENG_4 for libgcc as
RELENG_5?  libgcc under 5.x just has weak references to
pthread_foo() which get resolved when strongly referenced
by other things.  Won't this work in 4.x?  Since they are
weakly referenced, they don't need to be linked to libc_r.

-- 
Dan Eischen