Skip to content
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 from
Closed

Update glib and glibmm #453

wants to merge 2 commits into from

Conversation

lluixhi
Copy link
Contributor

@lluixhi 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
Copy link
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.

@TimothyGu TimothyGu modified the milestone: 2.24 Aug 10, 2014
@TimothyGu
Copy link
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?

@TimothyGu
Copy link
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);

@lluixhi lluixhi changed the title Update glib and glibmm to 2.41.2 Update glib and glibmm Aug 10, 2014
@lluixhi
Copy link
Contributor Author

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
Copy link
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.

@TimothyGu
Copy link
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().

@tonytheodore
Copy link
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.

@TimothyGu
Copy link
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.

@TimothyGu
Copy link
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.

@TimothyGu
Copy link
Member

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
Fixes mxe#400 and mxe#492.

See mxe#453.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>
@TimothyGu TimothyGu mentioned this pull request Oct 14, 2014
TimothyGu added a commit that referenced this pull request Oct 20, 2014
[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
Copy link
Member

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants