This is the mail archive of the mailing list for the binutils 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: PATCH: Re: other/9031

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
Red Hat GCC Developer                 aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist                Professional serial bug killer

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