#2221 mingw-w64-i686-glib2 g_fopen mode

MSYS2
closed
nobody
None
Bug
invalid
Unknown
False
2014-06-29
2014-06-29
Cedric Chantepie
No

GLib 2.0 used for package mingw-w64-i686-glib2 seems not to have been properly compiled.

According glib sources for same version (2.40), if G_OS_WIN32 g_fopen should use _wfopen, using given file mode (e.g. "r", "w", ...).

Using binary dist of glib2 installed by pacman, file mode is not honored: even passing "rb" (binary read), translation is applied which is wrong and prevent from recognizing signature or binary file (e.g. as required by gdk-pixbuf to detect image format).

Using attached test code with gnome-fs-directory.png, with glib2 package provided by msys2, line carriage is translated (5th byte translated to 10 instead of original 13).

Building same glib version from sources with following configure command, same test code is back to expected behaviour (read untranslated):

CPPFLAGS="-march=i686 -D_WIN32_WINNT=0x0601" LIBFFI_CFLAG=pkgconfig --cflags libffi LIBFFI_LIBS="-lffi -L/mingw32/lib/" ./configure --prefix=/mingw32 --with-python=which python

2 Attachments

Related

Issues: #2221

Discussion

  • Keith Marshall
    Keith Marshall
    2014-06-29

    • status: unread --> closed
    • Resolution: none --> invalid
     
    • Sorry? Why there is corresponding bug category/group there so?

      On 29 juin 2014 19:35:36 CEST, Keith Marshall keithmarshall@users.sf.net wrote:

      • status: unread --> closed
      • Resolution: none --> invalid
      • Comment:

      Wrong project! We support neither mingw-w64 nor msys2, both of which
      are independent (and separate) forks.


      [bugs:#2221] mingw-w64-i686-glib2 g_fopen mode

      Status: closed
      Group: MSYS2
      Created: Sun Jun 29, 2014 02:13 PM UTC by Cedric Chantepie
      Last Updated: Sun Jun 29, 2014 02:13 PM UTC
      Owner: nobody

      GLib 2.0 used for package mingw-w64-i686-glib2 seems not to have been
      properly compiled.

      According glib sources for same version (2.40), if G_OS_WIN32 g_fopen
      should use _wfopen, using given file mode (e.g. "r", "w", ...).

      Using binary dist of glib2 installed by pacman, file mode is not
      honored: even passing "rb" (binary read), translation is applied which
      is wrong and prevent from recognizing signature or binary file (e.g. as
      required by gdk-pixbuf to detect image format).

      Using attached test code with gnome-fs-directory.png, with glib2
      package provided by msys2, line carriage is translated (5th byte
      translated to 10 instead of original 13).

      Building same glib version from sources with following configure
      command, same test code is back to expected behaviour (read
      untranslated):

      CPPFLAGS="-march=i686 -D_WIN32_WINNT=0x0601" LIBFFI_CFLAG=pkgconfig --cflags libffi LIBFFI_LIBS="-lffi -L/mingw32/lib/" ./configure
      --prefix=/mingw32 --with-python=which python


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/mingw/bugs/2221/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Cédric Chantepie

       

      Related

      Issues: #2221

      • Keith Marshall
        Keith Marshall
        2014-06-29

        Sorry? Why there is corresponding bug category/group there so?

        It was always our intention that we would publish an MSYS2. However, the guy who has developed the prototype which is available today went off and did his own thing, without discussion with this project's members, and completely ignored our packaging standards. Thus, his implementation is a fork, and we do not support it.

        This is not to say that we will not, one day, support our own implementation, but that will be delivered via mingw-get, as all our products are, and will not be his incompatible implementation.

         
  • Keith Marshall
    Keith Marshall
    2014-06-29

    Wrong project! We support neither mingw-w64 nor msys2, both of which are independent (and separate) forks.