Re: gcc 3.0.1 does not work on Solaris 8/sparc

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20010906222916.A2729@mediaone.net> you write:

>>> I have tried building latest gcc (3.0.1, and also -current CVS checkout),
>>> with little success. The C compiler compiles, but libstdc++ blows up.
>>> The patch attached below works around the (known broken!) problem of "ln
>>> -s -f" not working in Solaris by doing an explicit 'rm' first.

>> Alexandre, do you know anything about this?  People (including me) have
>> definitely built on modern Solaris without issues.  Does this problem
>> ring any bells for you?  Is there autoconf magic to deal with this?

> This may be a shot in the dark, but Solaris comes with
> two versions of ln.  One is in /usr/ucb, and one is in /usr/bin.

Everyone, there is a lot more to this bug report than meets the eye.
For one, the Makefile.am segment in question DOES NOT set up to use
`ln' with the -f argument!  It uses @LN_S@ without any such flags.
Thus, the author of the report is mistaken to state that the root
problem is `-s -f' not working together with ln on Solaris...

One problem is that people that have been configuring gcc for 8 years
clearly do not bother to read release notes for major releases...

As I reported to the the user via private e-mail, his patch cannot be
correct since: (a) he patches Makefile.in when Makefile.am exists; and
(b) it is never correct to expand an autoconf/automake @@ variable
inline to correct an expansion problem.  I invited him to try again.

I believe that this problem has something do to with configuring
within the source directory AND using non-GNU make.  Granted, we want
to make it work, but the 3.0 release notes explicitly stated that it
is not the preferred way for a user to build for best results.  If
users don't follow our advice on how to get best results and don't get
best results, then I don't think we should listen to their rude
reports (I guess I am getting fed up reading all the users coming out
of the woodwork to complain that we don't volunteer enough time to
give them a modern compiler).

The root problem is that ln is returning an error code that kills
plain make on many systems but not GNU make.  Here is the sample
makefile that proves the issue (and it seems like deja vu):

; cat Makefile 
all: b

b: c
	(echo hi && ln -s a b); echo done

c:
	touch c

a:
	touch a

On FreeBSD 4.3-STABLE:

; make
(echo hi && ln -s a b); echo done
hi
ln: b: File exists
*** Error code 1

Stop in /tmp.
; gmake
(echo hi && ln -s a b); echo done
hi
ln: b: File exists
done
; 

On Solaris 2.7:

; /usr/ccs/bin/make
(echo hi && ln -s a b); echo done
hi
ln: b: File exists
*** Error code 1
make: Fatal error: Command failed for target `b'
; gmake
(echo hi && ln -s a b); echo done
hi
ln: b: File exists
done

I offer no patch to gcc since it is unclear to me whether this is an
automake/autoconf problem or our problem.

It is just plain dumb from a maintainer-effort standpoint to allow
users to build the software in a way that *zero* active developers are
using on a regular basis.  Recently, I have setup a daliy regression
platform to check in-source configuration but it still used GNU make
for both in-source and out-source configuration.  I suppose I will
have to force the use of BSD make one day and GNU make the next to
automatically catch another major source of bootstrap errors that
creep into the source tree.

Regards,
Loren