This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATH][Ada] Fix multilib handling of gnat.dg when RUNTESTFLAGS is used
* 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 ...
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.
Cheers,
Ralf