This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 16 Jan 2013 09:08:51 +0000
- Subject: [Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
- Auto-submitted: auto-generated
- References: <bug-52122-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-16 09:08:51 UTC ---
I'd say it is too late for autoconf update for 4.8 now, if this is about LN_S
uses in a single Makefile (are we talking about libada/Makefile.in ? ), you
could temporarily use something like
ifeq (cp -p,$(LN_S))
LN_S_RECURSIVE = cp -pR
else
LN_S_RECURSIVE = $(LN_S)
endif
(or even limit it to targets known to support cp -pR well that don't have ln
-s)
and use $(LN_S_RECURSIVE) in
$(LN_S) $(ADA_RTS_DIR) adainclude
$(LN_S) $(ADA_RTS_DIR) adalib
(2x) instead $(LN_S). Then for 4.9 we can upgrade autoconf requirements and
revert this.