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

[David O'Brien]

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".


> 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
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.

 
> > {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.


> > 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.

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.

-- 
-- David  (obrien at FreeBSD.org)