2016-02-07 19:12 GMT+01:00 David Macek: > The reason is to reduce unexpected behavior. In MSYS2, we want to build > software as close as > reasonably possible to Linux "originals". I can see that the WIN32/CYGWIN > stuff is there for a > reason, but it's more suited for Fossil as a stand-alone app on otherwise > graphical Windows.
Yes, I see. You are using msys2 as a kind of "minimal cygwin". Does that also mean that your fossil.exe depends on msys dll's? If so, I don't think that's suitable for a large public, it will work fine only in an msys2 environment. However, I looked at your patch, and I see the goal behind it. Thanks! >> BROKEN_MINGW_CMDLINE is meant for the original mingw only, for >> mingw-w64 everything's fine. For details, see: >> <http://sourceforge.net/p/mingw/bugs/771/> > > I tried it just now with v1.34 and I need to explicitly define it, otherwise > the build breaks with `undefined reference to `WinMain'` because of the > main/wmain change. It seems that in trunk, it gets defined automatically now. This looks like a missing "-municode" linker option. For details how to create a UNICODE-aware executable with mingw-w64, see: <https://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/> (B.T.W. : defining _UNICODE/UNICODE is not necessary for fossil, because it implicitly uses the wide API everywhere already). This is the only way I know which enables the use of _all_ unicode characters on the command line, not only the ones in the current windows code-page. Regards, Jan Nijtmans _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
