On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > 2012/3/16 Vincent Torri <vincent.to...@gmail.com> >> >> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem >> <vanboxem.ru...@gmail.com> wrote: >> > 2012/3/16 Vincent Torri <vincent.to...@gmail.com> >> >> >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem >> >> <vanboxem.ru...@gmail.com> wrote: >> >> > 2012/3/16 Vincent Torri <vincent.to...@gmail.com> >> >> >> >> >> >> 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
