After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591511 - hh-blob.c does not compile using mingw on windows
hh-blob.c does not compile using mingw on windows
Status: VERIFIED FIXED
Product: pango
Classification: Platform
Component: general
1.25.x
Other All
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2009-08-12 00:23 UTC by Bug ByteMan
Modified: 2009-08-15 04:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bug ByteMan 2009-08-12 00:23:41 UTC
Please describe the problem:
hh-blob.c (new to pango 1.25.2) can not be compiled using mingw on windows because it unconditionally tries to include sys/mman.h

Steps to reproduce:
1. configure and build using mingw on windows
2. 
3. 


Actual results:
hb-blob.c:32:22: sys/mman.h: No such file or directory
hb-blob.c: In function `hb_blob_try_writeable_inplace':
hb-blob.c:250: warning: implicit declaration of function `sysconf'
hb-blob.c:250: error: `_SC_PAGE_SIZE' undeclared (first use in this function)
hb-blob.c:250: error: (Each undeclared identifier is reported only once
hb-blob.c:250: error: for each function it appears in.)
hb-blob.c:269: warning: implicit declaration of function `mprotect'
hb-blob.c:269: error: `PROT_READ' undeclared (first use in this function)
hb-blob.c:269: error: `PROT_WRITE' undeclared (first use in this function)

Expected results:
Successful compile

Does this happen every time?
Yes

Other information:
Comment 1 Behdad Esfahbod 2009-08-12 12:56:27 UTC
Yep, got to fix that.  I will disable the mprotect call today.

Tor, can you at some point look into this and implement the win32 equivalent of mprotect?
Comment 2 Behdad Esfahbod 2009-08-12 23:39:36 UTC
commit 7380a171e933b8690146d2976caf0c5abafbed91
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Wed Aug 12 19:36:29 2009 -0400

    Bug 591511 – hb-blob.c does not compile using mingw on windows
    
    Only call mprotect() when available.  For optimal performance, a win32
    way to make memory writeable needs to be added.

Comment 3 Bug ByteMan 2009-08-13 06:14:13 UTC
I tried the latest version and HAVE_MPROTECT is getting defined in config.h.  It seems like the attempt to autodetect mprotect is not working.

I manually patched config.h to get past this issue.

The next issue (incompatibility with mingw/windows) is:

In file included from hb-buffer.c:28:
hb-buffer-private.h:66: error: size of array '_static_assert_on_line_66_failed'
is negative

I was able to fix the structure size mismatch by patching hb-common.h:

$ diff hb-common.h.org hb-common.h.mod
40c40
< typedef int hb_bool_t;
---
> typedef short hb_bool_t;
Comment 4 Erik van Pienbroek 2009-08-13 08:44:25 UTC
The ./configure test for mprotect always succeeds as that function is implemented in libgcc.a:

$ grep -Hr mprotect /usr/lib64/gcc/i686-pc-mingw32/*
Binary file /usr/lib64/gcc/i686-pc-mingw32/4.4.0/libgcc.a matches

Complete build logs (using the Fedora MinGW cross-compiler) can be found at http://koji.fedoraproject.org/koji/getfile?taskID=1602352&name=build.log
Comment 5 Behdad Esfahbod 2009-08-13 09:25:52 UTC
Ok, fixed the assertion.  Will make the mprotect call conditional on sys/mman.h being available.
Comment 6 Behdad Esfahbod 2009-08-13 09:28:11 UTC
Ok, fixed the mman.h issue too.  So, is the mprotect() in libgcc not usable?
Comment 7 Tor Lillqvist 2009-08-13 09:46:30 UTC
I think the mprotect() in mingw's libgcc is a mistake, perhaps unintentionally made public or something. Surely if they wanted to actually provide a mprotect() they should declare it in some header (presumably introduce a <sys/mman.h> like POSIX), along with the PROT_* constants. I mailed the mingw list about this.
Comment 8 Erik van Pienbroek 2009-08-13 09:49:19 UTC
The assertion still fails:

/bin/sh ../../libtool  --tag=CC   --mode=compile i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..  -DHAVE_GLIB -mms-bitfields -I/usr/i686-pc-mingw32/sys-root/mingw/include/glib-2.0 -I/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include     -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -mms-bitfields -MT libharfbuzz_la-hb-buffer.lo -MD -MP -MF .deps/libharfbuzz_la-hb-buffer.Tpo -c -o libharfbuzz_la-hb-buffer.lo `test -f 'hb-buffer.c' || echo './'`hb-buffer.c
libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -DHAVE_GLIB -mms-bitfields -I/usr/i686-pc-mingw32/sys-root/mingw/include/glib-2.0 -I/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -mms-bitfields -MT libharfbuzz_la-hb-buffer.lo -MD -MP -MF .deps/libharfbuzz_la-hb-buffer.Tpo -c hb-buffer.c  -DDLL_EXPORT -DPIC -o .libs/libharfbuzz_la-hb-buffer.o
In file included from hb-buffer.c:28:
hb-buffer-private.h:65: error: size of array '_static_assert_on_line_65_failed' is negative
hb-buffer-private.h:66: error: size of array '_static_assert_on_line_66_failed' is negative
make: *** [libharfbuzz_la-hb-buffer.lo] Error 1
Comment 9 Behdad Esfahbod 2009-08-13 15:49:54 UTC
Err, really fixed now.
Comment 10 Tor Lillqvist 2009-08-13 16:33:35 UTC
Shouldn't the new_advance bitfield in hb-buffer.h also be changed to unsigned short? Only then does it compile for me.
Comment 11 Behdad Esfahbod 2009-08-13 17:08:35 UTC
Forgot to push.  Should be all good now.
Comment 12 Erik van Pienbroek 2009-08-14 10:08:35 UTC
I can confirm that the compilation now succeeds on the Fedora MinGW cross-compiler: http://koji.fedoraproject.org/koji/buildinfo?buildID=127270
Comment 13 Behdad Esfahbod 2009-08-14 14:50:55 UTC
Cool.

Anyone want to give it a shot with VC compiler?
Comment 14 Bug ByteMan 2009-08-15 03:55:11 UTC
I can confirm that the compilation now succeeds on MinGW/Windows.

Thanks for all the hard work!