This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Ping.

Laurent

On Mon, 2009-03-16 at 14:15 +0100, Laurent GUERBY wrote:
> Ping.
> 
> So far the two people who tested LN_S on mingw32 reported success,
> that is it copied the directory.
> 
> Laurent
> 
> On Thu, 2009-03-05 at 22:15 +0100, Laurent GUERBY wrote:
> > 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
> > 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]