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
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Janis Johnson <janis187 at us dot ibm dot com>, Arnaud Charlet <charlet at adacore dot com>
- Date: Thu, 05 Mar 2009 12:57:05 +0100
- Subject: Re: [PATH][Ada] Fix multilib handling of gnat.dg when RUNTESTFLAGS is used
- References: <1236247879.11347.1296.camel@localhost> <49AFB5D6.8000607@gnu.org> <20090305114213.GA32108@ins.uni-bonn.de>
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?
Thanks in advance,
Laurent