Re: To compile glib on MinGW is not easy

Hash: SHA1

On 30.05.2014 17:09, Florian HEGRON wrote:
I compiled glib on my MinGW installation ! It's unbelievable.

I plaisant but this is because I try since many days (weeks).

My different problems (with glib 2.41.0) :

- There is a bug into mingw-libintl package I opened a ticket in the 
bug tracker system of the MinGW project [1].

.la files must not be installed. Removing .la files is THE right 

yes I understand that. You agree that is a bug of the mingw-libintl 
package ?


- There is a problem with rand_s in grand.c in Glib and Windows API 
provided with MinGW32. I saw that there are several patchs on several 
forums/bugtrackers but I can't make it to work. If anybody know more 
about this, thank you. My solution : I read the commit on git repo [2]
 and I unpatched glib.

Seems like problem. It might be possible to rewrite this
to use W32 CryptoAPI instead (XP-or-later, but i doubt that glib
maintains pre-XP compatibility anymore).

Ok I see. Mingw32 use the XP API yet ? I see on a bug tracker platform
that mingw64 doesn't have the problem. Do you know why mingw64 has not the
same API than mingw32.

It's "" and "mingw-w64", not "mingw32" and "mingw64".
You can google for "mingw-w64 vs", that should explain the situation.

- There is a last problem with Python when I "make install". The error
 : python can't read /usr/bin/sh. My solution : I install Python
(2.7.6), I add the path into $PATH, and I modified the 
glib-2.41.0/bld/gio/gdbus-2.0/codegen/Makefile file. On line 538, I 
delete "PYTHON = /usb/bin/env python25" and wrote "PYTHON = ". And at
 the line 199, I change "am__py_compile = $(PYTHON) $(SHELL)
$(py_compile)" by "am__py_compile = $(SHELL) $(py_compile)". I didn't
test but I think that the error is juste the "/usr/bin/env". I think
that there is a bug with the ./configure script because in the
Makefile files, the value of the PYTHON variable was "/usr/bin/env
python25" but, at the beginning, I didn't have Python installed on my

This is kind of complicated. Personally, i have W32 CPython integrated 
into my MinGW-w64 installation, and i also have MSYS2-Python installed.
 Other people use MinGW-CPython instead of W32 CPython. Either way,
things seem to work out just fine for me. Your description of the
problem (not the solution) is kind of short, so i have no idea why would
Python try to read /usr/bin/sh.

I didn't find that (Mingw-CPython). May be that I didn't enough search.

CPython is the Python implementation from

W32-CPython is CPython built with MSVC and distributed by
MinGW-CPython is CPython built with MinGW (or MinGW-w64) (which requires a
number of patches at the moment, there are issues open on Python bugtracker
for this).

Do you know the rules to integrate or not a software on the Mingw-get 
plateform ?

Probably not (i've poked mingw-get a bit once, then just gave up).

I really want to help to make glib more easy to compile and install. 
So say me what can I do to help the project. Do you want that I make
a specific test and show to you the result ?

I don't know. Not many people care about these days. It's 
hard enough to make glib devs accept patches that are
MinGW-w64-compatible, with it's going to be even harder.

Ok. I don't understand the reason. Do devs think that cygwin is a best 
method to compile on windows ? Do not they care about Windows ?

I don't know what the devs think.

Cygwin is a good method. MSYS2 is even better, IMO. MSYS - not so much.

And on top of that you need, orthogonally, a toolchain, which could be or MinGW-w64. As you've experienced, at the moment is not
very well-supported, unlike MinGW-w64.

- -- 
O< ascii ribbon - stop html email! -
Version: GnuPG v1.4.11 (MingW32)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]