From Kurt.Hornik at wu-wien.ac.at  Fri Nov  5 08:53:59 2004
From: Kurt.Hornik at wu-wien.ac.at (Kurt Hornik)
Date: Fri Nov  5 08:54:17 2004
Subject: [Rd] 2.0.1 buglets
In-Reply-To: <x24qk55jlf.fsf@biostat.ku.dk>
References: <Pine.LNX.4.44.0411042113220.22863-100000@gannet.stats>
	<x28y9h5kdy.fsf@biostat.ku.dk> <x24qk55jlf.fsf@biostat.ku.dk>
Message-ID: <16779.12695.207382.732792@mithrandir.hornik.net>

>>>>> Peter Dalgaard writes:

> Peter Dalgaard <p.dalgaard@biostat.ku.dk> writes:
>> > > but everything seems to configure and make ok. Should this message be 
>> > > expect or is this a bug?
>> > 
>> > It is unexpected.  Is it new in 2.0.1 beta?  You have told us your kernel,
>> > not your distro.  This looks like a bug, but not in R.
>> 
>> I've seen it whizz by occasionally but never got around to
>> investigate. As said, it doesn't actually affect the result of
>> configure.

> I can't seem to reproduce this exactly, but on Solaris I have

> checking for xmkmf... /usr/X/bin/xmkmf
> /home/bs/sfesys/sysadm/export/common.alias: No such file or directory
> /home/bs/sfesys/sysadm/export/common.alias: No such file or directory
> /home/bs/sfesys/sysadm/export/common.alias: No such file or directory
> /home/bs/sfesys/sysadm/export/common.alias: No such file or directory

> This was with the 2.0.0 sources, so it isn't new. The culprit appears
> to be constructions like

>   if test "`which ${cc}`" = "`which ${CC}`"; then
>     shlib_ldflags=`${srcdir}/tools/GETMAKEVAL SHLIBLDFLAGS`
>     cpicflags=`${srcdir}/tools/GETMAKEVAL PICFLAGS`
>   fi

> in configure.ac.  I guess we shouldn't really use "which" at all...

In which case we need other means to figure out whether ${cc} and ${CC}
are the same.  (In the sense that they have the same pathname.)

Shell scripts for doing so will be appreciated.

(Actually, I would think that the above points to an incorrect imake
configuration.)

-k


[Rd] 2.0.1 buglets
Kurt Hornik