2015-01-25 21:36 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: > On Sun, Jan 25, 2015 at 7:44 PM, James Almer <jamr...@gmail.com> wrote: > > > On 25/01/15 2:47 PM, Hendrik Leppkes wrote: > > > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer <michae...@gmx.at > > > > > wrote: > > > > > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > > >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > > >>>> On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes < > h.lepp...@gmail.com > > > > > >>>> wrote: > > >>>> > > >>>>> MSYS2 uses a system name of "MSYS_NT-6.3" instead of > > >> "MINGW32_NT-6.3" in > > >>>>> MSYS1. > > >>>>> > > >>>> > > >>>> Apparently this isn't quite correct, and you have to start MSYS2 > with > > a > > >>>> special batch file that overrides this for you. > > >>>> Just running bash.exe or sh.exe from a DOS prompt results in this > and > > >> is > > >>>> apparently considered "wrong usage". > > >>> > > >>> I don't really see anything wrong with this, however I'd rather have > > >>> a compiler-based detection. > > >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless > > >>> set explicitly). > > >> > > >>> This should also address my other annoyance that you have to specify > > >>> --host when it really should be obvious that you are cross-compiling > to > > >>> MINGW for example. > > >> > > >> i dont use "--host*" for my mingw building > > >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 > > --target-os=mingw32 > > >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine > > >> > > >> the rest i use should not be mingw specific > > >> > > >> > > > I've never had to specify --host things either, the only problem with > > MSYS2 > > > I ran into was that you still need to specify --target-os unless you > use > > > their fancy batch file, and that tripped me up a bit. > > > Never a problem with old MSYS and my own gcc build. > > > > As you said the old MSYS uses "MINGW32" as part of the system name, while > > the > > normal batch file for MSYS2 sets it as "MSYS". > > If you instead use the x86 batch file it will be set as "MINGW32", or > > "MINGW64" > > if you use the x86_64 batch file. > > > > The different batch files exist not just to change the output of uname, > > but also > > to change the PATH environment variable too include either /mingw32 or > > /mingw64 > > respectively. Their package manager offers a complete toolchain and > > precompiled > > libraries, which get installed in one of the two folders above. > > Ideally speaking, if you don't want to use their gcc toolchains, you > should > > install your own in some other folder (/usr/local, /opt, etc) and use the > > normal > > batch file. > > > > configure currently only checks for mingw32 since that's what MSYS sets, > > so it > > needs to be updated to also check for mingw64 and msys, so this patch is > > IMO > > correct but incomplete as its missing the check for the former. > > > > > My problem really is with their choice of default. Apparently (or so I am > told), the MSYS_* string is for building things actually for MSYS itself, > which is imho a bad default. > If I just call sh/bash.exe (like I do in a multitude of my scripts), I > wouldn't want that to be the default value, especially since it breaks with > compat for all sorts of projects (we're not the only project with that > problem) > > I agree that this change of behavior comparing to MSYS1 can be confusing. But I think they made it sane enough. If we set MSYSTEM environmental variable to MINGW32 anywhere before call to sh/bash.exe it will present itself as MINGW32_* and work fine. This doesn't require any tricks just one env variable to be set. Additionally when calling "bash --login" it will alter PATH to include /mingw32 bin dir, but this is optional if we take care about it ourself.
As for the path itself I think it is incorrect because we can't consider MSYS and MINGW the same thing. - Kacper _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
