From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25007 invoked by alias); 8 Aug 2012 21:10:42 -0000 Received: (qmail 24998 invoked by uid 22791); 8 Aug 2012 21:10:41 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Aug 2012 21:10:28 +0000 From: "tim.vanholder at anubex dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files Date: Wed, 08 Aug 2012 21:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tim.vanholder at anubex dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.4 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg00463.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 tim.vanholder at anubex dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tim.vanholder at anubex dot | |com --- Comment #6 from tim.vanholder at anubex dot com 2012-08-08 21:10:24 UTC --- Daniel, your patch modifies the configure scripts, which are generated files - so the effect would be temporary at best. I don't have a gcc checkout handy (nor high-speed internet), so I can't check this myself right now, but: - If the configure.ac scripts use autoconf's own AC_LN_S macro, then a bug report should be submitted to the autoconf maintainers, and a GCC_LN_S macro would probably have to be created with the fix in place (to avoid depending on an upstream fix). Of course if autoconf uses all this internally, an upstream fix may be the only avenue. - If a gcc-specific macro is already being used (grep for "ln" or "cp -p" in the top-level "config" subdir (*.m4) to get an idea), then just put the fix(es) there Based on the variables seen in your patch it's probably going to be both (as_ln_s is an autoshell (part of autoconf) variable, gcc_cv_prog_LN_S sounds like a GCC-specific one). Once the macros are added/fixed, whatever script/command regenerates all the gcc configure scripts will propagate those changes automatically (and they will stay present even if a user regenerates a configure script). Note: I think I see an LN="cp -p" remain untouched in your patch - surely if the "ln -s" replacement needs to support directories, so does the one for plain ln?