Re: bfd and cygpath

[Peter Rosin <peda at lysator dot liu dot se>]

On 2013-04-26 18:51, NightStrike wrote:
> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin <peda@lysator.liu.se> wrote:
>> On 2013-04-26 13:58, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin <peda@lysator.liu.se> wrote:
>>>> On 2013-04-24 22:24, NightStrike wrote:
>>>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike <nightstrike@gmail.com> wrote:
>>>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <peda@lysator.liu.se> wrote:
>>>>>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>>>>>> that.
>>>>>>
>>>>>> Where is the actual test that runs when that option is set?  I can't find it.
>>>>
>>>> It's in the LT_PATH_LD macro, a loop is broken out of like this:
>>>>
>>>>       case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
>>>>       *GNU* | *'with BFD'*)
>>>>         test no != "$with_gnu_ld" && break
>>>>         ;;
>>>>       *)
>>>>         test yes != "$with_gnu_ld" && break
>>>>         ;;
>>>>       esac
>>>>
>>>> But reading it more carefully, it appears as if $LD is not clobbered if already
>>>> set by the user (and if $LD is preset by the user I read it as if --with-gnu-ld
>>>> indeed forces libtool to treat $LD is GNU ld). Do you feed a preset $LD to
>>>> configure? Does anything else in configure set $LD before the expansion of
>>>> LT_PATH_LD runs?
>>>
>>> I don't explicitly set LD in top level configure, no.  I thought it
>>> was being set via the output of gcc -print-prog-name=ld, as per my
>>> last post.  I could be wrong.
>>
>> I had a look in the binutils src (2.23.51) and its top level configure
>> has this:
>>
>> # We must set the default linker to the linker used by gcc for the correct
>> # operation of libtool.  If LD is not defined and we are using gcc, try to
>> # set the LD default to the ld used by gcc.
>> if test -z "$LD"; then
>>   if test "$GCC" = yes; then
>>     case $build 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
>>     case $gcc_prog_ld in
>>     # Accept absolute paths.
>>     [\\/]* | [A-Za-z]:[\\/]*)
>>       LD="$gcc_prog_ld" ;;
>>     esac
>>   fi
>> fi
>>
>> Notice that it does not canonicalize gcc_prog_ld prior to the assignment
>> of LD (which is done in the LT_PATH_LD macro). I think this is what
>> causes LD to have the value it has in the bfd configure. I notice that
>> you are using a configure cache as well, which might me responsible for
>> carrying the LD value over to bfd.
> 
> But if I set LD myself in the configure line, then it shouldn't
> exercise this code and should pass the LD over to bfd configure
> unmodified.

Right, that was more a note that cleared up why the LD value wasn't
canonicalized, which confused me at first.

>> But c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>> or c:/mingw32/i686-w64-mingw32/bin/ld.exe
>> should be mear cosmetics (since you are not playing mount/symlink games).
>>
>> What do you get if you run:
>>
>> c:/mingw32/i686-w64-mingw32/bin/ld.exe -v </dev/null
>>
>> (which is what _LT_PATH_LD_GNU runs to determine if you are using GNU ld)
> 
> No such file or directory, which is to be expected.  It's a wine path.
>  Gcc can execute that because gcc is running under wine.  But I can't
> run that directly from a bash shell.

And that is the crux of the matter. No matter what you do, libtool
will still check $LD to see if it is gnu ld. Besides, if libtool
can't execute $LD, things look pretty bleak. So, I guess you will
have to override $LD.

>>>> The reason I ask is because your $LD result
>>>>         c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>>>> hasn't been canonicalized. I'd expect it to be
>>>>         c:/mingw32/i686-w64-mingw32/bin/ld.exe
>>>> but the canonicalized version is only assigned to $LD if $LD isn't set
>>>> already.
>>>>
>>>> BTW, have you played mount games that perhaps fools the naive c14n?
>>>
>>> I don't know what c14n is.  I'm not trying to play mount games, but I
>>> am running in a hybrid wine environment.
>>
>> c14n -> canonicalization, like i18n and l10n.
>>
>>>> Hmm, I also see this:
>>>>
>>>>   case $host in
>>>>   *-*-mingw*)
>>>>     # gcc leaves a trailing carriage return which upsets mingw
>>>>     ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
>>>>   *)
>>>>     ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
>>>>   esac
>>>>
>>>> Does your $host match *-*-mingw*?
>>>
>>> Yes, build==host==target==i686-w64-mingw32 using 32-bit wine on linux.
>>
>> Ok.
>>
>>>>> I found this:
>>>>> configure:5654: checking for ld used by gcc
>>>>> configure:5721: result:
>>>>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>>>>> configure:5728: checking if the linker
>>>>> (c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe)
>>>>> is GNU ld
>>>>> configure:5743: result: no
>>>>
>>>> The above is (partial) output from LT_PATH_LD.
>>>>
>>>>> So here's a problem...   It's getting that linker instead of just
>>>>> using $CC because it grabbed the output of gcc -print-prog, which is
>>>>> using a windows style path.
>>>>
>>>> Windows style pathnames shouldn't be a problem on MSYS. I assume you are
>>>> on MSYS?
>>>
>>> Nope.  wine.
>>>
>>>> It's perhaps time to send the full config.log...
>>>
>>> Ok, will try setting LD and will send with and without that.
>>
>> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You
>> might try LD=i686-w64-mingw32-ld instead, but you shouldn't need to
>> specify LD...
> 
> I'll try LD=i68...-ld, but libtool should really fix that.

I humbly disagree. What you are doing is not supported. You are effectively
"lying" (using the terminology of the libtool manual) to configure (by
claiming you are on a MinGW host, when in fact you are on a Linux host).
Compare with the Libtool manual section 15.3.7.6

http://www.gnu.org/software/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross

but think Linux/Wine instead of Cygwin as the build. When you have fixed
this issue, you will probably bump into something else. E.g., I guess you
should specify:
     export lt_cv_to_host_file_cmd=func_convert_file_nix_to_w32
     export lt_cv_to_tool_file_cmd=func_convert_file_nix_to_w32

Further, will not the dependency tracking output from the MinGW gcc
generate a bunch of w32 paths that mixes badly with Linux make?

Are you absolutely sure that you have to "lie" to configure? Why not do
the decent thing and leave --host unspecified so that config.guess can
do its thing?

And if you don't "lie", you might as well use a linux-hosted cross-compiler
targeting mingw and just rely on wine to run testsuites etc. But even if
you move from the "lying" case to the "fake" case (i.e. still using the
mingw-hosted native compiler in wine), chances are that it will work
better that the "lying" case. But I don't know that, haven't tried...

The reason the "lying" and "fake" cases work when crossing from Cygwin
to MinGW is that the true build system (Cygwin) understands w32 based
paths (most of the time anyway). Your true build system (Linux) does not,
so you are in uncharted territory.

>>>>> What I don't understand is why it isn't just using gcc as the linker,
>>>>> instead of ld.
>>>>
>>>> It's the way it has been done for a long time, I think originally bugs
>>>> (bugs now long gone) caused libtool devs to sidestep the frontend when
>>>> linking (instead of fixing upstream). And you are not the first to ask.
>>>> I'm sure most would be happy to see this change. I'm also sure some
>>>> will be upset by regressions...
>>>
>>> This is probably a sure path to success.  Every piece of documentation
>>> I've ever read on GCC says not to call ld directly.  How do we get
>>> this changed?
>>
>> Search me.  Sorry.
> 
> Darn.  I was hoping you had the inside track on libtool.

I just don't feel confident enough to tackle it and haven't even really
looked into it. Besides, it's not causing me any troubles as I normally
don't "lie" and "fake". So, no itch.