2012/3/16 Vincent Torri <[email protected]>
> On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem
> <[email protected]> wrote:
> > 2012/3/16 Vincent Torri <[email protected]>
> >>
> >> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem
> >> <[email protected]> wrote:
> >> > 2012/3/16 Vincent Torri <[email protected]>
> >> >>
> >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
> >> >> <[email protected]> wrote:
> >> >> > 2012/3/16 Vincent Torri <[email protected]>
> >> >> >>
> >> >> >> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
