[Mingw-w64-public] wrong ar.exe name in ruben's build ?
hey in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it normal ? Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/16 Vincent Torri > hey > > in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it > normal ? > I think it is. These seem to be related to GCC plugins, and do not appear in my 4.6.4 build for example. When I try to run them, I get an error about the program not being built with plugins (probably cause I didn't enable them explicitely in binutils or gcc or something). The original binutils binaries were never prefixed, so I'd say just ignore them and use the prefixless versions. Ruben > > Vincent Torri > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem wrote: > 2012/3/16 Vincent Torri >> >> hey >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it >> normal ? > > > I think it is. These seem to be related to GCC plugins, and do not appear in > my 4.6.4 build for example. When I try to run them, I get an error about the > program not being built with plugins (probably cause I didn't enable them > explicitely in binutils or gcc or something). The original binutils binaries > were never prefixed, so I'd say just ignore them and use the prefixless > versions. the problem i had is that if I pass --host=foobar, the autotools search for foobar-ar and not foobar-gcc-ar, hence an error Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/16 Vincent Torri > On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem > wrote: > > 2012/3/16 Vincent Torri > >> > >> hey > >> > >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it > >> normal ? > > > > > > I think it is. These seem to be related to GCC plugins, and do not > appear in > > my 4.6.4 build for example. When I try to run them, I get an error about > the > > program not being built with plugins (probably cause I didn't enable them > > explicitely in binutils or gcc or something). The original binutils > binaries > > were never prefixed, so I'd say just ignore them and use the prefixless > > versions. > > the problem i had is that if I pass --host=foobar, the autotools > search for foobar-ar and not foobar-gcc-ar, hence an error > It should always fall back to non-prefixed versions (on MSYS at least), causing no issues. Ruben > > Vincent Torri > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
于 2012/3/16 23:22, Ruben Van Boxem 写道: > I think it is. These seem to be related to GCC plugins, and do not > appear in my 4.6.4 build for example. When I try to run them, I get an > error about the program not being built with plugins (probably cause I > didn't enable them explicitely in binutils or gcc or something). The > original binutils binaries were never prefixed, so I'd say just ignore > them and use the prefixless versions. You should build binutils using --enable-plugin x86_64-w64-mingw32-gcc-ar.exe is a ar plugin wrapper -- Best Regards, xunxun -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem wrote: > 2012/3/16 Vincent Torri >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem >> wrote: >> > 2012/3/16 Vincent Torri >> >> >> >> hey >> >> >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named >> >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it >> >> normal ? >> > >> > >> > I think it is. These seem to be related to GCC plugins, and do not >> > appear in >> > my 4.6.4 build for example. When I try to run them, I get an error about >> > the >> > program not being built with plugins (probably cause I didn't enable >> > them >> > explicitely in binutils or gcc or something). The original binutils >> > binaries >> > were never prefixed, so I'd say just ignore them and use the prefixless >> > versions. >> >> the problem i had is that if I pass --host=foobar, the autotools >> search for foobar-ar and not foobar-gcc-ar, hence an error > > > It should always fall back to non-prefixed versions (on MSYS at least), > causing no issues. well, some autotooled programs/libraries rely on the host to compile in some wpecific way. So i don't think it's always good t rely on the non prefix versions Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/16 Vincent Torri > On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem > wrote: > > 2012/3/16 Vincent Torri > >> > >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem > >> wrote: > >> > 2012/3/16 Vincent Torri > >> >> > >> >> hey > >> >> > >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > >> >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is > it > >> >> normal ? > >> > > >> > > >> > I think it is. These seem to be related to GCC plugins, and do not > >> > appear in > >> > my 4.6.4 build for example. When I try to run them, I get an error > about > >> > the > >> > program not being built with plugins (probably cause I didn't enable > >> > them > >> > explicitely in binutils or gcc or something). The original binutils > >> > binaries > >> > were never prefixed, so I'd say just ignore them and use the > prefixless > >> > versions. > >> > >> the problem i had is that if I pass --host=foobar, the autotools > >> search for foobar-ar and not foobar-gcc-ar, hence an error > > > > > > It should always fall back to non-prefixed versions (on MSYS at least), > > causing no issues. > > well, some autotooled programs/libraries rely on the host to compile > in some wpecific way. So i don't think it's always good t rely on the > non prefix versions > When compiling natively there is no problem, even when you specify host, autotools defaults to the non-prefixed versions. Linux users do it all the time. Native toolchains are non-prefixed by definition/design. Blame GNU for that if you think it is wrong or broken. You can always copy ar.exe if you feel the need. I haven't encountered any autotools project that does not work in this way wrt this detail. Ruben > Vincent Torri > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem wrote: > 2012/3/16 Vincent Torri >> >> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem >> wrote: >> > 2012/3/16 Vincent Torri >> >> >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem >> >> wrote: >> >> > 2012/3/16 Vincent Torri >> >> >> >> >> >> hey >> >> >> >> >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named >> >> >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is >> >> >> it >> >> >> normal ? >> >> > >> >> > >> >> > I think it is. These seem to be related to GCC plugins, and do not >> >> > appear in >> >> > my 4.6.4 build for example. When I try to run them, I get an error >> >> > about >> >> > the >> >> > program not being built with plugins (probably cause I didn't enable >> >> > them >> >> > explicitely in binutils or gcc or something). The original binutils >> >> > binaries >> >> > were never prefixed, so I'd say just ignore them and use the >> >> > prefixless >> >> > versions. >> >> >> >> the problem i had is that if I pass --host=foobar, the autotools >> >> search for foobar-ar and not foobar-gcc-ar, hence an error >> > >> > >> > It should always fall back to non-prefixed versions (on MSYS at least), >> > causing no issues. >> >> well, some autotooled programs/libraries rely on the host to compile >> in some wpecific way. So i don't think it's always good t rely on the >> non prefix versions > > > When compiling natively there is no problem, even when you specify host, > autotools defaults to the non-prefixed versions. Linux users do it all the > time. Native toolchains are non-prefixed by definition/design. Blame GNU for > that if you think it is wrong or broken. You can always copy ar.exe if you > feel the need. I haven't encountered any autotools project that does not > work in this way wrt this detail. > i've just compiled binutils (latest release) myself with --host=x86_64-w64-mingw32, and it failed, saying that x86_64-w64-mingw32-ar.exe was not found. I had to rename it Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/16 Vincent Torri > On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem > wrote: > > 2012/3/16 Vincent Torri > >> > >> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem > >> wrote: > >> > 2012/3/16 Vincent Torri > >> >> > >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem > >> >> wrote: > >> >> > 2012/3/16 Vincent Torri > >> >> >> > >> >> >> hey > >> >> >> > >> >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > >> >> >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. > Is > >> >> >> it > >> >> >> normal ? > >> >> > > >> >> > > >> >> > I think it is. These seem to be related to GCC plugins, and do not > >> >> > appear in > >> >> > my 4.6.4 build for example. When I try to run them, I get an error > >> >> > about > >> >> > the > >> >> > program not being built with plugins (probably cause I didn't > enable > >> >> > them > >> >> > explicitely in binutils or gcc or something). The original binutils > >> >> > binaries > >> >> > were never prefixed, so I'd say just ignore them and use the > >> >> > prefixless > >> >> > versions. > >> >> > >> >> the problem i had is that if I pass --host=foobar, the autotools > >> >> search for foobar-ar and not foobar-gcc-ar, hence an error > >> > > >> > > >> > It should always fall back to non-prefixed versions (on MSYS at > least), > >> > causing no issues. > >> > >> well, some autotooled programs/libraries rely on the host to compile > >> in some wpecific way. So i don't think it's always good t rely on the > >> non prefix versions > > > > > > When compiling natively there is no problem, even when you specify host, > > autotools defaults to the non-prefixed versions. Linux users do it all > the > > time. Native toolchains are non-prefixed by definition/design. Blame GNU > for > > that if you think it is wrong or broken. You can always copy ar.exe if > you > > feel the need. I haven't encountered any autotools project that does not > > work in this way wrt this detail. > > > > i've just compiled binutils (latest release) myself with > --host=x86_64-w64-mingw32, and it failed, saying that > x86_64-w64-mingw32-ar.exe was not found. I had to rename it > You can also use AR= and similar for the missing stuff. Did you try specifying build as well? Ruben > > Vincent Torri > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Fri, Mar 16, 2012 at 5:18 PM, Ruben Van Boxem wrote: > > You can also use AR= and similar for the missing stuff. sure, but the cross compilation should work without modification. > Did you try specifying build as well? i don't understand Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/16 Vincent Torri > On Fri, Mar 16, 2012 at 5:18 PM, Ruben Van Boxem > wrote: > > > > You can also use AR= and similar for the missing stuff. > > sure, but the cross compilation should work without modification. > That's the thing: my toolchains (at least the windows ones) aren't cross-compilers. The linux cross-compilers I built have all binaries prefixed. > > > Did you try specifying build as well? > > i don't understand > pass --build=x86_64-w64-mingw32 to configure. I just checked under MSYS, it works as it should. Ruben > > Vincent Torri > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On 16/3/2012 4:52 PM, Vincent Torri wrote: > the problem i had is that if I pass --host=foobar, the autotools > search for foobar-ar and not foobar-gcc-ar, hence an error > gcc-ar is not the same as ar from binutils. That is something that comes with gcc 4.7. While I'm not quite sure what is does, I'm guessing that is not something you should use directly. -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Wed, Mar 21, 2012 at 5:39 PM, Christer Solskogen wrote: > On 16/3/2012 4:52 PM, Vincent Torri wrote: > >> the problem i had is that if I pass --host=foobar, the autotools >> search for foobar-ar and not foobar-gcc-ar, hence an error >> > > gcc-ar is not the same as ar from binutils. That is something that comes > with gcc 4.7. While I'm not quite sure what is does, I'm guessing that > is not something you should use directly. then that's problematic... There is a tool that I don't know what it does, and setting host will result in failing because of a missing ***-ar.exe Vincent Torri -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On 21/3-2012 5:45 PM, Vincent Torri wrote: > then that's problematic... There is a tool that I don't know what it > does, and setting host will result in failing because of a missing > ***-ar.exe > But that's most probably your fault. You have configured binutils wrong, or you don't have binutils at all. If configured and installed correctly you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have installed a cross-binutils). -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Wed, Mar 21, 2012 at 7:10 PM, Christer Solskogen wrote: > On 21/3-2012 5:45 PM, Vincent Torri wrote: > >> then that's problematic... There is a tool that I don't know what it >> does, and setting host will result in failing because of a missing >> ***-ar.exe >> > > But that's most probably your fault. You have configured binutils wrong, > or you don't have binutils at all. If configured and installed correctly > you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have > installed a cross-binutils). No, not my fault. I've always used both automatic build and Ruben's build before his last release. It always worked fine. I used the last one, boum error. And I should build by myself binutils, as it is provided by mingw-w64... Vincent -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/21 Vincent Torri > On Wed, Mar 21, 2012 at 7:10 PM, Christer Solskogen > wrote: > > On 21/3-2012 5:45 PM, Vincent Torri wrote: > > > >> then that's problematic... There is a tool that I don't know what it > >> does, and setting host will result in failing because of a missing > >> ***-ar.exe > >> > > > > But that's most probably your fault. You have configured binutils wrong, > > or you don't have binutils at all. If configured and installed correctly > > you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have > > installed a cross-binutils). > > No, not my fault. I've always used both automatic build and Ruben's > build before his last release. It always worked fine. > > I used the last one, boum error. > What tool are you talking about, what build system is failing, etc..? You're not giving us anything to work with here. If you give details, preferably stuff I/we can try to reproduce, I/we could help you. The fact remains that your story does not make any sense, and I think an unexpected operator error has snuck in. (Reproducible) Details would clarify. Ruben > And I should build by myself binutils, as it is provided by mingw-w64... > > Vincent > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Wed, Mar 21, 2012 at 7:22 PM, Ruben Van Boxem wrote: > 2012/3/21 Vincent Torri >> >> On Wed, Mar 21, 2012 at 7:10 PM, Christer Solskogen >> wrote: >> > On 21/3-2012 5:45 PM, Vincent Torri wrote: >> > >> >> then that's problematic... There is a tool that I don't know what it >> >> does, and setting host will result in failing because of a missing >> >> ***-ar.exe >> >> >> > >> > But that's most probably your fault. You have configured binutils wrong, >> > or you don't have binutils at all. If configured and installed correctly >> > you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have >> > installed a cross-binutils). >> >> No, not my fault. I've always used both automatic build and Ruben's >> build before his last release. It always worked fine. >> >> I used the last one, boum error. > > > What tool are you talking about, what build system is failing, etc..? You're > not giving us anything to work with here. If you give details, preferably > stuff I/we can try to reproduce, I/we could help you. The fact remains that > your story does not make any sense, and I think an unexpected operator error > has snuck in. (Reproducible) Details would clarify. my original mail : "in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it normal ?" did you read it ? Vincent -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/21 Vincent Torri : > my original mail : > > "in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it > normal ?" I asked about this, too: http://gcc.gnu.org/ml/gcc-help/2011-12/msg00211.html, but noone doesn't know about it. -- Regards, niXman -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/21 Vincent Torri > On Wed, Mar 21, 2012 at 7:22 PM, Ruben Van Boxem > wrote: > > 2012/3/21 Vincent Torri > >> > >> On Wed, Mar 21, 2012 at 7:10 PM, Christer Solskogen > >> wrote: > >> > On 21/3-2012 5:45 PM, Vincent Torri wrote: > >> > > >> >> then that's problematic... There is a tool that I don't know what it > >> >> does, and setting host will result in failing because of a missing > >> >> ***-ar.exe > >> >> > >> > > >> > But that's most probably your fault. You have configured binutils > wrong, > >> > or you don't have binutils at all. If configured and installed > correctly > >> > you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have > >> > installed a cross-binutils). > >> > >> No, not my fault. I've always used both automatic build and Ruben's > >> build before his last release. It always worked fine. > >> > >> I used the last one, boum error. > > > > > > What tool are you talking about, what build system is failing, etc..? > You're > > not giving us anything to work with here. If you give details, preferably > > stuff I/we can try to reproduce, I/we could help you. The fact remains > that > > your story does not make any sense, and I think an unexpected operator > error > > has snuck in. (Reproducible) Details would clarify. > > my original mail : > > "in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named > x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it > normal ?" > > did you read it ? > No need to get snide. I read each of your emails, and even replied to most of them. Did you read my answers? The only concrete example of a failing project you gave, was binutils, which as Kai and I pointed out, you misconfigured by not specifying the "--build" option, implicitely telling autotools you were cross-compiling, resulting in it wanting a "-ar". Nowhere in that little story did any reference to any "-gcc-ar" ever pop up. Autotools doesn't even check for such an executable. Ignore these new executables, because as Xunxun already said (in mail 3 of the thread, they are related to the GCC-binutils plugin architecture, which wasn't enabled for my build. Delete them for all I care. Now unless you have a problem that hasn't already been solved, please *refrain* from *not giving* details which might actually get your unknown problem solved. Ruben > Vincent > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Wed, Mar 21, 2012 at 7:57 PM, Ruben Van Boxem wrote: > 2012/3/21 Vincent Torri >> >> On Wed, Mar 21, 2012 at 7:22 PM, Ruben Van Boxem >> wrote: >> > 2012/3/21 Vincent Torri >> >> >> >> On Wed, Mar 21, 2012 at 7:10 PM, Christer Solskogen >> >> wrote: >> >> > On 21/3-2012 5:45 PM, Vincent Torri wrote: >> >> > >> >> >> then that's problematic... There is a tool that I don't know what it >> >> >> does, and setting host will result in failing because of a missing >> >> >> ***-ar.exe >> >> >> >> >> > >> >> > But that's most probably your fault. You have configured binutils >> >> > wrong, >> >> > or you don't have binutils at all. If configured and installed >> >> > correctly >> >> > you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have >> >> > installed a cross-binutils). >> >> >> >> No, not my fault. I've always used both automatic build and Ruben's >> >> build before his last release. It always worked fine. >> >> >> >> I used the last one, boum error. >> > >> > >> > What tool are you talking about, what build system is failing, etc..? >> > You're >> > not giving us anything to work with here. If you give details, >> > preferably >> > stuff I/we can try to reproduce, I/we could help you. The fact remains >> > that >> > your story does not make any sense, and I think an unexpected operator >> > error >> > has snuck in. (Reproducible) Details would clarify. >> >> my original mail : >> >> "in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it >> normal ?" >> >> did you read it ? > > > No need to get snide. I read each of your emails, and even replied to most > of them. Did you read my answers? > > The only concrete example of a failing project you gave, was binutils, it's the only concrete project that failed because it was the first one i tried with your mingw-w64 build... See below. > which > as Kai and I pointed out, you misconfigured by not specifying the "--build" > option, implicitely telling autotools you were cross-compiling, resulting in > it wanting a "-ar". Nowhere in that little story did any reference > to any "-gcc-ar" ever pop up. Autotools doesn't even check for such > an executable. of course it does ! i took one of my libs that i cross often compile. I configured it in MSYS by setting --host=i686-w64-mingw32 result: checking for i686-w64-mingw32-ar... no checking for ar... ar So it does check for i686-w64-mingw32-ar... I've used cross compilation with mingw-w64 for several years, i've never had such problems, until your build. Now if you think that your gcc 4.7 build is fine, no problem, i'll use another one (4.6.2, as it works). Vincent -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On 21/3-2012 8:46 PM, Vincent Torri wrote: >> as Kai and I pointed out, you misconfigured by not specifying the "--build" >> option, implicitely telling autotools you were cross-compiling, resulting in >> it wanting a "-ar". Nowhere in that little story did any reference >> to any "-gcc-ar" ever pop up. Autotools doesn't even check for such >> an executable. > > of course it does ! > No, it does not. > i took one of my libs that i cross often compile. I configured it in > MSYS by setting --host=i686-w64-mingw32 > > result: > > checking for i686-w64-mingw32-ar... no > checking for ar... ar > > So it does check for i686-w64-mingw32-ar... > And Ruben just told you that it does not check for i686-w64-mingw32-gcc-ar. Forget about *-gcc-ar already! And no, ar and gcc-ar is not the same thing even if you want it to. -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/21 Christer Solskogen : > On 21/3-2012 8:46 PM, Vincent Torri wrote: > >>> as Kai and I pointed out, you misconfigured by not specifying the "--build" >>> option, implicitely telling autotools you were cross-compiling, resulting in >>> it wanting a "-ar". Nowhere in that little story did any reference >>> to any "-gcc-ar" ever pop up. Autotools doesn't even check for such >>> an executable. >> >> of course it does ! >> > > No, it does not. > >> i took one of my libs that i cross often compile. I configured it in >> MSYS by setting --host=i686-w64-mingw32 >> >> result: >> >> checking for i686-w64-mingw32-ar... no >> checking for ar... ar >> >> So it does check for i686-w64-mingw32-ar... >> > > And Ruben just told you that it does not check for i686-w64-mingw32-gcc-ar. > > Forget about *-gcc-ar already! And no, ar and gcc-ar is not the same > thing even if you want it to. > > -- > chs There are actual more of those -gcc-* executables. Namely -gcc-ar.exe -gcc-nm.exe -gcc-ranlib.exe The are generated by plugin-feature. Simply ignore them, I don't expect that you might actaul want them to use. Kai -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On Wed, Mar 21, 2012 at 9:28 PM, Christer Solskogen wrote: > On 21/3-2012 8:46 PM, Vincent Torri wrote: > >>> as Kai and I pointed out, you misconfigured by not specifying the "--build" >>> option, implicitely telling autotools you were cross-compiling, resulting in >>> it wanting a "-ar". Nowhere in that little story did any reference >>> to any "-gcc-ar" ever pop up. Autotools doesn't even check for such >>> an executable. >> >> of course it does ! >> > > No, it does not. > >> i took one of my libs that i cross often compile. I configured it in >> MSYS by setting --host=i686-w64-mingw32 >> >> result: >> >> checking for i686-w64-mingw32-ar... no >> checking for ar... ar >> >> So it does check for i686-w64-mingw32-ar... >> > > And Ruben just told you that it does not check for i686-w64-mingw32-gcc-ar. ok, i misread that. Anyway, the fact that i686-w64-mingw32-ar is missing *is* a problem i stop that conversation, now, it goes nowhere Vincent -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
2012/3/21 Vincent Torri : > On Wed, Mar 21, 2012 at 9:28 PM, Christer Solskogen > wrote: >> On 21/3-2012 8:46 PM, Vincent Torri wrote: >> as Kai and I pointed out, you misconfigured by not specifying the "--build" option, implicitely telling autotools you were cross-compiling, resulting in it wanting a "-ar". Nowhere in that little story did any reference to any "-gcc-ar" ever pop up. Autotools doesn't even check for such an executable. >>> >>> of course it does ! >>> >> >> No, it does not. >> >>> i took one of my libs that i cross often compile. I configured it in >>> MSYS by setting --host=i686-w64-mingw32 >>> >>> result: >>> >>> checking for i686-w64-mingw32-ar... no >>> checking for ar... ar >>> >>> So it does check for i686-w64-mingw32-ar... >>> >> >> And Ruben just told you that it does not check for i686-w64-mingw32-gcc-ar. > > ok, i misread that. > > Anyway, the fact that i686-w64-mingw32-ar is missing *is* a problem > > > i stop that conversation, now, it goes nowhere Ok, but please remember about the advice of using --build option here for binutils. As I assume you have instead build native ar.exe etc. Kai -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
On 21/3-2012 10:00 PM, Vincent Torri wrote: > Anyway, the fact that i686-w64-mingw32-ar is missing *is* a problem > That is true :-) Try downloading Rubens build again and unpack it with a decent zipper (7z/pk7zip for example) -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
