Re: [PATH][Ada] Fix multilib handling of gnat.dg when RUNTESTFLAGS is used

[Laurent GUERBY <laurent at guerby dot net>]

On Thu, 2009-03-05 at 21:05 +0100, Ralf Wildenhues wrote:
> * Laurent GUERBY wrote on Thu, Mar 05, 2009 at 12:57:05PM CET:
> > On Thu, 2009-03-05 at 12:42 +0100, Ralf Wildenhues wrote:
> > > * Paolo Bonzini wrote on Thu, Mar 05, 2009 at 12:21:58PM CET:
> > > > I am not sure that symbolic links to directories are okay on all
> > > > platforms where Ada is supported (especially MinGW).
> > > 
> > > Well, if LN_S is 'cp -p', the above won't do the right thing, so using
> > > $(LN_S) can't be right here.
> > 
> > "cp -pr" works on both file and directories, some googling
> > seems to imply that's what happens on MinGW:
> > 
> > http://svn.opengroupware.org/SOPE/trunk/gnustep-make/config.make.in
> > # Special case - on mingw32, autoconf sets LN_S to 'ln -s', but then
> > # that does a recursive copy (ie, cp -r).
> > ifeq (@target_os@,mingw32)
> >   HAS_LN_S = no
> > endif
> > 
> > But I couldn't get direct confirmation, if you have a mingw32 build tree
> > around could you do "grep LN_S build/config.log" and test the result on
> > a directory?
> 
> IIRC then MinGW was changed at one point to emulate "ln -s"; I don't
> know whether it emulates it as 'cp -r' if the source is a directory.
> 
> However, the Autoconf configure test definitely sets LN_S to 'cp -p' on
> some systems, including some versions of MinGW (or some file systems
> there, or whatever).  Details matter, of course, but the gist is that
> with the Autoconf 2.59 version that GCC currently uses you cannot use
> $(LN_S) to link to a directory.  You can probably use
>   ln -s ... || cp -pr ...

autoconf 2.59 has:

<<
echo >conf$$.file
if ln -s conf$$.file conf$$ 2>/dev/null; then
  # We could just check for DJGPP; but this test a) works b) is more generic
  # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04).
  if test -f conf$$.exe; then
    # Don't use ln at all; we don't have any links
    as_ln_s='cp -p'
  else
    as_ln_s='ln -s'
  fi
elif ln conf$$.file conf$$ 2>/dev/null; then
  as_ln_s=ln
else
  as_ln_s='cp -p'
fi
rm -f conf$$ conf$$.exe conf$$.file
>>

Is mingw "ln -s" really creating this magic "conf$$.exe" file? If not it
looks like "ln -s" will be used, no? I guess as you mentioned this can
vary with the mingw version, in the current gcc/doc/install.texi we
mention:

<<
GCC will build with and support only MinGW runtime 3.12 and later.
Earlier versions of headers are incompatible with the new default
semantics of @code{extern inline} in @code{-std=c99} and
@code{-std=gnu99} modes.
>>

Do you know since what version "ln" behave as we want? Is by any chance
3.12 ok?

> in the rules.
> 
> I can check if it's worth changing Autoconf to set LN_S to 'cp -pr'
> instead of 'cp -p', but my gut reaction would be that copying a whole
> directory tree may be both way too expensive, and also problematic with
> VPATH make rules, for it to be practically useful.

Thanks for your input. 

Looks like I opened a can of worm :).

Laurent