gcc 3.0.1 does not work on Solaris 8/sparc

[Loren James Rittle]

Hi Mark,

>>> OK.  That suggests that writing `$(LN_S) -f' anywhere is probably
>>> a mistake; we need an autoconf test to get us an LN_SF that works.

>> Is there a reason against using the simple and portable
>>   rm -f somelink
>>   ln -s /usr/bin somelink

Yes! There is a reason.  That code is not portable nor does it express
what is currently used in libstdc++-v3/include/Makefile.am.

A lot of people are getting stuck on a complete red herring.

Run: find libstdc++-v3 -name 'Makefile*' -exec grep LN_S '{}' \;

On no platform do the libstdc++-v3 Makefiles get built to call 'ln -s
-f'.  There is no use of the construct `$(LN_S) -f' (actually that
itself is a minor typo: the construct in automake files is @LN_S@ not
$(LN_S) ).  It just doesn't happen.  The orignal report that claims we
use ``ln -s -f'' unportably is in error.

> Seems reasonable to me.  V3 people, would you look into making this
> change so that the Makefiles are more portable?

It does seem reasonable to make things more portable, but in my mind,
Makefile.am using @LN_S@ is correct.  Expanding that in Makefile.am to
use 'rm -f target; ln -s source target' is wrong since the whole
reason to use @LN_S@ was to make things more portable.

Explicit use of rm and ln in Makefile.am is NOT portable.

One correct fix might be to force non-GNU make to ignore the return
code from ln -s like GNU make is doing.  I.e.:

(@LN_S@ [...] || true)

Someone might be tempted to convert the construct to 

@RM_F@ target; @LN_S@ source target

Be aware that may break a commonly used configuration strategy (that
should have been banned a long time ago...)

BTW, I have no commit access until next week due to local networking
issues that broke my ssh path.  I can provide a patch but someone else
will have to bootstrap it and install it.

Regards,
Loren