New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update glib and glibmm #453

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@lluixhi
Contributor

lluixhi commented Aug 9, 2014

I don't know if this was in anybody's interest, but I did it -- all this does is update the patches to work with the new version.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2014

Member

I don't know if this was in anybody's interest

Yes of course!!!

I'll run some testing on this and will merge this once I think this is OK.

Member

TimothyGu commented Aug 10, 2014

I don't know if this was in anybody's interest

Yes of course!!!

I'll run some testing on this and will merge this once I think this is OK.

@TimothyGu TimothyGu modified the milestone: 2.24 Aug 10, 2014

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2014

Member

OK, I tried to build glib on i686-pc-mingw32.shared, and it failed. The problem is that MinGW does not provide a prototype for rand_s() (see http://sourceforge.net/p/mingw/bugs/2122/). However mingw-w64 does.

This bug is fairly hard to fix, because all three options seem rather unrealistic:

  1. Patch mingwrt using a variant of http://sourceforge.net/p/mingw/bugs/2122/attachment/rand_s-mingw.patch
    The patch only applies to mingwrt 4.*, applying it on 3.20 (which mxe uses) is possible but rather difficult because currently mxe simply gets the binary and installs it. Patching means getting the source and build it, and all sorts of chicken vs. egg problem appears.

  2. Disable glib on i686-pc-mingw32.
    glib is crucial to many projects:

    timothy_gu@ubuntu-lenovo:~/mxe$ make show-downstream-deps-glib
    agg atk atkmm cegui chromaprint ffmpeg freetype fribidi ftgl gd gdk-pixbuf
    glibmm graphicsmagick gst-plugins-base gst-plugins-good gstreamer gtk2
    gtkglarea gtkglext gtkglextmm gtkimageview gtkmm2 gtksourceview
    gtksourceviewmm2 harfbuzz imagemagick lensfun libass libbluray libcaca
    libcroco libgda libgdamm libgee libglade libgsf liblqr-1 librsvg libxml++
    mdbtools ocaml-cairo ocaml-camlimages ocaml-lablgl ocaml-lablgtk2 opencv
    openscenegraph pango pangomm pcl plotmm poppler qscintilla2 qt5 qtactiveqt
    qtbase qtconnectivity qtdeclarative qtenginio qtgraphicaleffects
    qtimageformats qtlocation qtmultimedia qtquick1 qtquickcontrols qtscript
    qtsensors qtserialport qtservice qtsvg qtsystems qttools qttranslations
    qtwebkit qtwebsockets qtwinextras qtxmlpatterns qwt sdl2_ttf sdl_pango sdl_ttf
    sfml t4k_common vtk wt xine-lib
    

    Without glib the purpose of mxe is basically diminished.

  3. Remove i686-pc-mingw32.
    There are still packages that can only be built with MinGW, and removing this target isn't very nice.

So, I propose that we either figure out a way to make MinGW use the old version while mingw-w64 the new one, or to delay this update. @tonytheodore?

Member

TimothyGu commented Aug 10, 2014

OK, I tried to build glib on i686-pc-mingw32.shared, and it failed. The problem is that MinGW does not provide a prototype for rand_s() (see http://sourceforge.net/p/mingw/bugs/2122/). However mingw-w64 does.

This bug is fairly hard to fix, because all three options seem rather unrealistic:

  1. Patch mingwrt using a variant of http://sourceforge.net/p/mingw/bugs/2122/attachment/rand_s-mingw.patch
    The patch only applies to mingwrt 4.*, applying it on 3.20 (which mxe uses) is possible but rather difficult because currently mxe simply gets the binary and installs it. Patching means getting the source and build it, and all sorts of chicken vs. egg problem appears.

  2. Disable glib on i686-pc-mingw32.
    glib is crucial to many projects:

    timothy_gu@ubuntu-lenovo:~/mxe$ make show-downstream-deps-glib
    agg atk atkmm cegui chromaprint ffmpeg freetype fribidi ftgl gd gdk-pixbuf
    glibmm graphicsmagick gst-plugins-base gst-plugins-good gstreamer gtk2
    gtkglarea gtkglext gtkglextmm gtkimageview gtkmm2 gtksourceview
    gtksourceviewmm2 harfbuzz imagemagick lensfun libass libbluray libcaca
    libcroco libgda libgdamm libgee libglade libgsf liblqr-1 librsvg libxml++
    mdbtools ocaml-cairo ocaml-camlimages ocaml-lablgl ocaml-lablgtk2 opencv
    openscenegraph pango pangomm pcl plotmm poppler qscintilla2 qt5 qtactiveqt
    qtbase qtconnectivity qtdeclarative qtenginio qtgraphicaleffects
    qtimageformats qtlocation qtmultimedia qtquick1 qtquickcontrols qtscript
    qtsensors qtserialport qtservice qtsvg qtsystems qttools qttranslations
    qtwebkit qtwebsockets qtwinextras qtxmlpatterns qwt sdl2_ttf sdl_pango sdl_ttf
    sfml t4k_common vtk wt xine-lib
    

    Without glib the purpose of mxe is basically diminished.

  3. Remove i686-pc-mingw32.
    There are still packages that can only be built with MinGW, and removing this target isn't very nice.

So, I propose that we either figure out a way to make MinGW use the old version while mingw-w64 the new one, or to delay this update. @tonytheodore?

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2014

Member

Some more greps:

timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-pc-mingw32.shared/include/*
timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-w64-mingw32.shared/include/*
usr/i686-w64-mingw32.shared/include/stdlib.h:  _CRTIMP errno_t __cdecl rand_s(unsigned int *randomValue);
Member

TimothyGu commented Aug 10, 2014

Some more greps:

timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-pc-mingw32.shared/include/*
timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-w64-mingw32.shared/include/*
usr/i686-w64-mingw32.shared/include/stdlib.h:  _CRTIMP errno_t __cdecl rand_s(unsigned int *randomValue);

@lluixhi lluixhi changed the title from Update glib and glibmm to 2.41.2 to Update glib and glibmm Aug 10, 2014

@lluixhi

This comment has been minimized.

Show comment
Hide comment
@lluixhi

lluixhi Aug 10, 2014

Contributor

It seems it's also a problem in 2.40.0..
There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

Contributor

lluixhi commented Aug 10, 2014

It seems it's also a problem in 2.40.0..
There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2014

Member

Yes, and in 2.39.1. See GNOME/glib@0e1924a. Another solution is to revert the said commit, but that would make it unsupported and untested by upstream.

Member

TimothyGu commented Aug 10, 2014

Yes, and in 2.39.1. See GNOME/glib@0e1924a. Another solution is to revert the said commit, but that would make it unsupported and untested by upstream.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2014

Member

There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

We can probably use the unsecured rand().

Member

TimothyGu commented Aug 10, 2014

There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

We can probably use the unsecured rand().

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Aug 10, 2014

Member

So, I propose that we either figure out a way to make MinGW use the old version

I suppose it's the same general question for recent versions of qt5 and supplementing directx headers - how much do we continue supporting MinGW when mingw-w64 is more current and MinGW v4 seems to be on hold?

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

Member

tonytheodore commented Aug 10, 2014

So, I propose that we either figure out a way to make MinGW use the old version

I suppose it's the same general question for recent versions of qt5 and supplementing directx headers - how much do we continue supporting MinGW when mingw-w64 is more current and MinGW v4 seems to be on hold?

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 17, 2014

This doesn't work. The offending commit is in since 2.39.1.

TimothyGu commented on 6db6072 Aug 17, 2014

This doesn't work. The offending commit is in since 2.39.1.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 17, 2014

Member

Replying to @tonytheodore:

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

Yes. Most projects I knew switched to mingw-w64, simply because MinGW is dead.

Member

TimothyGu commented Aug 17, 2014

Replying to @tonytheodore:

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

Yes. Most projects I knew switched to mingw-w64, simply because MinGW is dead.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Sep 3, 2014

Member

Any more opinions on this? If not, I say we should delay this pull request until after the release which can happen in anywhere between 1 and 4 months depending on the availability of @tonytheodore.

Member

TimothyGu commented Sep 3, 2014

Any more opinions on this? If not, I say we should delay this pull request until after the release which can happen in anywhere between 1 and 4 months depending on the availability of @tonytheodore.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 8, 2014

Member

Now in #492 we have decided not to support MinGW anymore. I will merge this in about a week after some more testing.

Member

TimothyGu commented Oct 8, 2014

Now in #492 we have decided not to support MinGW anymore. I will merge this in about a week after some more testing.

TimothyGu added a commit to TimothyGu/mxe that referenced this pull request Oct 14, 2014

Remove i686-pc-mingw32
Fixes #400 and #492.

See #453.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>

@TimothyGu TimothyGu referenced this pull request Oct 14, 2014

Merged

Remove i686-pc-mingw32 #529

TimothyGu added a commit that referenced this pull request Oct 20, 2014

Merge branch 'update-glib'
[Lluixhi Scura]
- Update glib and glibmm to 2.41.2

[Timothy Gu]
- Update glib and glibmm to 2.42.0

This merges pull request #453.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>
@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 20, 2014

Member

Merged, thanks! I also have updated the two packages to 2.42.0.

Member

TimothyGu commented Oct 20, 2014

Merged, thanks! I also have updated the two packages to 2.42.0.

@TimothyGu TimothyGu closed this Oct 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment