From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12217 invoked by alias); 27 Dec 2002 03:16:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12201 invoked by uid 71); 27 Dec 2002 03:16:02 -0000 Date: Thu, 26 Dec 2002 19:16:00 -0000 Message-ID: <20021227031602.12196.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Alexandre Oliva Subject: Re: PATCH: Re: other/9031 Reply-To: Alexandre Oliva X-SW-Source: 2002-12/txt/msg01306.txt.bz2 List-Id: The following reply was made to PR other/9031; it has been noted by GNATS. From: Alexandre Oliva To: "John David Anglin" Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, dave.anglin@nrc.ca, gcc-patches@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: PATCH: Re: other/9031 Date: 27 Dec 2002 01:11:11 -0200 On Dec 26, 2002, "John David Anglin" wrote: > The enclosed patch fixes the problem reported in other/9031. The > technique for determining LD is derived from that used by the > libtool AC_PROG_LD macro. > + case $host in > + *-*-mingw*) > + gcc_prog_ld="`$CC -print-prog-name=ld 2>&1 | tr -d '\015'`" ;; > + *) > + gcc_prog_ld="`$CC -print-prog-name=ld 2>&1`" ;; > + esac I don't think this is appropriate. If mingw's CRs are causing trouble, they'd cause trouble when mingw is the build machine, not the host. So perhaps it would be more reasonable to change case $host to case $build. Besides, I suppose the problem may actually be caused by the unnecessary use of double quotes in the assignment. I *think* taking them out may cause the needless CR to go away without affecting anything else. Another issue is that CC's ending with gcc may not be a good test for whether the host compiler is CC. I realize this is not the only occurrence of case $CC in *gcc) in the configure script, but even that one should IMHO be changed so as to use something more similar to autoconf's test for whether we are using GNU C. Also, pathname canonicalization is tricky business. Replacing foo/../ with / is only a good idea when foo is not a soft link. Do we really need this? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer