This is the mail archive of the
mailing list for the binutils project.
Re: bfd and cygpath
- From: Peter Rosin <peda at lysator dot liu dot se>
- To: NightStrike <nightstrike at gmail dot com>
- Cc: Libtool List <libtool at gnu dot org>, binutils <binutils at sourceware dot org>
- Date: Fri, 26 Apr 2013 23:55:25 +0200
- Subject: Re: bfd and cygpath
- References: <CAF1jjLvtiySDHS7WqrNaSYA3sxqLk-wVzm=EQuPpORda72B5AA at mail dot gmail dot com> <CAF1jjLvsn8oy0D+=MFYDiON3UW+ocBTZT1G347RHGcCEt9fkDQ at mail dot gmail dot com> <51777FF9 dot 2020105 at lysator dot liu dot se> <CAF1jjLtfvAkqCnCKxGp95nzSHbo1zMTU_ccahQ=-SEujXfXQmg at mail dot gmail dot com> <CAF1jjLuZ5zSB+y_JFA5YH0_Q3N1LG9=-yFoWsz4R9iugVsc1GA at mail dot gmail dot com> <CAF1jjLvtL_8ZUyreQstgUhU9zoDqpxFs=dwmyyrne52FKg6WZA at mail dot gmail dot com> <51783A08 dot 4050906 at lysator dot liu dot se> <CAF1jjLuVMg-AZ8na6OYG2cvenv2k5PDnfxXhHGFZLisNkdQteg at mail dot gmail dot com> <CAF1jjLv=f6dwM1cvU02Mrbe0fvK+w=EHJ+zQbdt7zjaJfhbpCQ at mail dot gmail dot com> <5178D295 dot 50603 at lysator dot liu dot se> <CAF1jjLssvtgbEMrtNFevMywrXgjniC1yc3gn_x6vh-U+RNu_hw at mail dot gmail dot com> <517A89C8 dot 6080000 at lysator dot liu dot se> <CAF1jjLsRigqbeXKnjmQ4hV=OAJkGyni_vv8WYQcqRJoeomZBaQ at mail dot gmail dot com> <517AF61D dot 8000803 at lysator dot liu dot se>
On 2013-04-26 23:48, Peter Rosin wrote:
> On 2013-04-26 18:51, NightStrike wrote:
>> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin <firstname.lastname@example.org> wrote:
>>> 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 188.8.131.52
> 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
Oops, --build, not --host.
> 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.