In /usr/include/unicode/pwin32.h there is conflict with recent /usr/include/sys/types.h header file in definition of int64_t. Reproducible: Always Steps to Reproduce: 1. Try to compile this C source file with GCC: #include <sys/types.h> #include <unicode/pwin32.h> int main() { return 0; } Actual Results: Error occured: In file included from test.c:2:0: /usr/include/unicode/pwin32.h:152:30: error: conflicting types for 'int64_t' /usr/include/sys/types.h:198:1: note: previous declaration of 'int64_t' was here Expected Results: Program should compile and run properly. This error causes breakages of builds of app-emulation/wine and possibly (seems my build error was because of this bug) of app-office/libreoffice.
Created attachment 262355 [details, diff] pwin32.h patch Dirty done-in-5-minutes patch to fix this bug.
Created attachment 262357 [details] Build log of app-emulation/wine Buildlog of app-emulation/wine after my quickfix, this error is gone, but there is a lot of other ones (which existed before fix too). Maybe, it is not error of dev-libs/icu, but app-emulation/wine instead? Sorry for my misunderstanding then.
Created attachment 262489 [details] environment (app-emulation/wine)
*** Bug 354757 has been marked as a duplicate of this bug. ***
I use sys-libs/glibc-2.12.2 and I can reproduce this problem.
Please file upstream at icu-project.org The quick patch doesn't make much sense to my 5 minute read :) .. we need to know why autoconf isn't detecting the types properly. What does sys/types.h say? What does your config.log say? Maybe attach those to the upstream bug. Thanks, srl of icu Arfrever thanks for the cc. (In reply to comment #0) > In /usr/include/unicode/pwin32.h there is conflict with recent > /usr/include/sys/types.h header file in definition of int64_t. > > Reproducible: Always
(In reply to comment #6) > Please file upstream at icu-project.org > > The quick patch doesn't make much sense to my 5 minute read :) .. we need to > know why autoconf isn't detecting the types properly. What does sys/types.h > say? What does your config.log say? Maybe attach those to the upstream bug. > > Thanks, srl of icu > > Arfrever thanks for the cc. > > (In reply to comment #0) > > In /usr/include/unicode/pwin32.h there is conflict with recent > > /usr/include/sys/types.h header file in definition of int64_t. > > > > Reproducible: Always > Yes, I know it, just tried to fix compiler errors when first encountered with this problem and doesn't knew about reasons of it. It could be marked as obsolete.
(In reply to comment #6) Actually I am not sure if this is a bug in ICU. unicode/pwin32.h is documented as "Configuration constants for the Windows platform". unicode/umachine.h includes unicode/pwin32.h only when __MINGW32__ is not defined and at least one of the following is defined: WIN32, _WIN32, WIN64, _WIN64. $ cat test.c #include <sys/types.h> #include <unicode/utypes.h> $ gcc -c test.c $ gcc -DWIN32 -c test.c In file included from /usr/include/unicode/umachine.h:50, from /usr/include/unicode/utypes.h:36, from test.c:2: /usr/include/unicode/pwin32.h:152: error: conflicting types for ‘int64_t’ /usr/include/sys/types.h:198: note: previous declaration of ‘int64_t’ was here In file included from /usr/include/unicode/utf.h:230, from /usr/include/unicode/utypes.h:37, from test.c:2: /usr/include/unicode/utf8.h: In function ‘__declspec’: /usr/include/unicode/utf8.h:91: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UChar32’ /usr/include/unicode/utf8.h:103: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int32_t’ /usr/include/unicode/utf8.h:115: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UChar32’ /usr/include/unicode/utf8.h:127: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int32_t’ In file included from /usr/include/unicode/utypes.h:38, from test.c:2: /usr/include/unicode/uversion.h:57: error: storage class specified for parameter ‘UVersionInfo’ /usr/include/unicode/uversion.h:152: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ /usr/include/unicode/uversion.h:166: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ /usr/include/unicode/uversion.h:182: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ /usr/include/unicode/uversion.h:193: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ In file included from test.c:2: /usr/include/unicode/utypes.h:307: error: storage class specified for parameter ‘UDate’ /usr/include/unicode/utypes.h:365: error: storage class specified for parameter ‘UClassID’ In file included from test.c:2: /usr/include/unicode/utypes.h:824: error: storage class specified for parameter ‘UErrorCode’ /usr/include/unicode/utypes.h:861: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ /usr/include/unicode/utypes.h:824: error: declaration for parameter ‘UErrorCode’ but no such parameter /usr/include/unicode/utypes.h:365: error: declaration for parameter ‘UClassID’ but no such parameter /usr/include/unicode/utypes.h:307: error: declaration for parameter ‘UDate’ but no such parameter /usr/include/unicode/uversion.h:57: error: declaration for parameter ‘UVersionInfo’ but no such parameter /usr/include/unicode/utf8.h:62: error: declaration for parameter ‘utf8_countTrailBytes_46’ but no such parameter test.c:2: error: expected ‘{’ at end of input Wine contains optional support for libxml2 (also see bug #354757). libxml2 >=2.7.8 contains optional support for ICU (libxml/encoding.h includes unicode/ucnv.h when libxml2 has been installed with support for ICU). sys/types.h of glibc defines: /* For GCC 2.7 and later, we can use specific type-size attributes. */ # define __intN_t(N, MODE) \ typedef int int##N##_t __attribute__ ((__mode__ (MODE))) # define __u_intN_t(N, MODE) \ typedef unsigned int u_int##N##_t __attribute__ ((__mode__ (MODE))) # ifndef __int8_t_defined # define __int8_t_defined __intN_t (8, __QI__); __intN_t (16, __HI__); __intN_t (32, __SI__); __intN_t (64, __DI__); /* Line 198 */ # endif Steven R. Loomis: Does ICU project support setting WIN32, _WIN32, WIN64 or _WIN64 on non-Windows systems?
(In reply to comment #8) > (In reply to comment #6) > > Actually I am not sure if this is a bug in ICU. > > unicode/pwin32.h is documented as "Configuration constants for the Windows > platform". unicode/umachine.h includes unicode/pwin32.h only when __MINGW32__ > is not defined and at least one of the following is defined: WIN32, _WIN32, > WIN64, _WIN64. … > > Steven R. Loomis: Does ICU project support setting WIN32, _WIN32, WIN64 or > _WIN64 on non-Windows systems? > I don't think that's usually done… anyways, maybe our autoconf logic needs to be updated, or we should detect __u_intN_t
*** Bug 355491 has been marked as a duplicate of this bug. ***
Well, from 'man winegcc': winegcc defines __WINE__, for code that needs to know when it is being compiled under Wine. It also defines WIN32, _WIN32, __WIN32, __WIN32__, __WINNT, and __WINNT__ for compatibility with MinGW. So, it seems that __MINGW32__ should be extended to cover __WINE__.
Created attachment 263081 [details, diff] patch for icu allowing wine to compile (In reply to comment #11) > Well, from 'man winegcc': > winegcc defines __WINE__, for code that needs to know when it is being > compiled under Wine. It also defines WIN32, _WIN32, __WIN32, __WIN32__, > __WINNT, and __WINNT__ for compatibility with MinGW. > > So, it seems that __MINGW32__ should be extended to cover __WINE__. Almost :) __WINE__ is defined for code that is being compiled *under* Wine, using winegcc. However, when compiling Wine itself, what is defined is __WINESRC__, not __WINE__. And we must also patch unicode/umachine.h; otherwise, building wine would run into the following error: In file included from /usr/include/unicode/utf.h:230:0, from /usr/include/unicode/utypes.h:37, from /usr/include/unicode/ucnv_err.h:86, from /usr/include/unicode/ucnv.h:50, from /usr/include/libxml2/libxml/encoding.h:31, from /usr/include/libxml2/libxml/parser.h:807, from /var/tmp/portage/app-emulation/wine-1.3.14/work/wine-1.3.14/dlls/msxml3/msxml_private.h:163, from /var/tmp/portage/app-emulation/wine-1.3.14/work/wine-1.3.14/dlls/msxml3/attribute.c:32: /usr/include/unicode/utf8.h:60:18: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ /usr/include/unicode/utf8.h:91:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UChar32’ /usr/include/unicode/utf8.h:103:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int32_t’ /usr/include/unicode/utf8.h:115:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UChar32’ /usr/include/unicode/utf8.h:127:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int32_t’ The attached patch for icu-4.6 ensures that __WINESRC__ is treated the same as __MINGW32__ in pwin32.h and umachine.h. With the patched icu, wine (with USE="X alsa cups dbus fontconfig gecko gnutls gphoto2 gsm jack jpeg lcms ldap mp3 ncurses openal opengl oss perl png pulseaudio samba scanner ssl threads truetype win32 win64 xcomposite xinerama xml") correctly compiles against libxml2-2.7.8 with USE=icu.
Wine can include libxml2 headers in the following way: #ifdef WIN32 #define WIN32_DEFINED #undef WIN32 #endif #ifdef _WIN32 #define _WIN32_DEFINED #undef _WIN32 #endif #ifdef WIN64 #define WIN64_DEFINED #undef WIN64 #endif #ifdef _WIN64 #define _WIN64_DEFINED #undef _WIN64 #endif #include <libxml/parser.h> #ifdef WIN32_DEFINED #define WIN32 #endif #ifdef _WIN32_DEFINED #define _WIN32 #endif #ifdef WIN64_DEFINED #define WIN64 #endif #ifdef _WIN64_DEFINED #define _WIN64 #endif
(In reply to comment #13) > Wine can include libxml2 headers in the following way: Given the choice between a large patch to at least 10 different files in wine that would likely have to be updated with every version bump, and a tiny patch to two files in icu that contain broken Windows header detection, the second option is IMHO more logical.
(In reply to comment #14) You would have to convince ICU upstream developers in https://ssl.icu-project.org/trac .
(In reply to comment #15) > (In reply to comment #14) > > You would have to convince ICU upstream developers in > https://ssl.icu-project.org/trac . Are you saying that you will not apply any patches that are not accepted by icu upstream?
(In reply to comment #16) Yes. We don't want to diverge from upstream.
(In reply to comment #17) OK. Considering the number of >5 year old open bug repots in icu trac, expecting a quick ack from icu developers - without which you will not commit patches - is clearly unrealistic. So for all intents and purposes, this bug will not be fixed on the icu end of things. Therefore, please reassign this bug report to wine@gentoo.org, since it appears that they are the ones who will have to fix it.
wine isnt the only broken package, although you'll get the same response. but winehq.org's bug tracker is a lot more responsive. looks to me still though that icu is being dumb and rather than have every single package out there that happens to use icu (directly or indirectly), fix the stupid package.
Created attachment 263115 [details, diff] patch for wine to build against unpatched icu As an alternative to the icu patch above, here is a patch for wine that allows it to build against an unpatched icu-4.6 and libxml2 with USE=icu. As you can see, although fixing the bug on the wine side certainly is possible, the patch is quite a bit larger, uglier, and more likely to require additional work on version bumps.
*** Bug 355679 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > looks to me still though that icu is being dumb and rather than have every > single package out there that happens to use icu (directly or indirectly), > fix the stupid package. I think that very small (close to 1) number of packages define WIN32, _WIN32, WIN64 or _WIN64 on non-Windows systems. I have several packages installed, which use ICU (e.g. sqlite, boost, xerces-c, webkit-gtk, openldap, libxml2) and they don't have any problems with ICU.
*** Bug 355701 has been marked as a duplicate of this bug. ***
Would it be possible to add epatch_user to the icu ebuild? This way anyone who chooses to use the patch for icu can just put it in /etc/portage/patches/dev-libs/icu and then remove it when/if icu ever fixes it. This way you don't have to "diverge from upstream" and, for those of us that it doesn't matter, we can easily patch without having to maintain this in a local overlay.
A much simpler fix would be to just add -DU_HAVE_INTTYPES_H=1 to Wine.
*** Bug 355839 has been marked as a duplicate of this bug. ***
Created attachment 263277 [details] script for generating wrappers around unicode headers Unfortunately my previous suggestion doesn't work because of other problems. This script generates wrappers around unicode headers, wrapping them in the save and restore code written by Alexandre. Use together with the ebuild patch that follows. I've successfully compiled Wine 1.3.14 on ~amd64, with wine64 flag.
Created attachment 263279 [details, diff] Ebuild patch to use the wrapper
Created attachment 263283 [details] script for generating wrappers around unicode headers Improved wrapper. The previous one had a problem with nested including of unicode headers (one unicode header includes another one), because it would restore the macros after the inner most header instead of after the outer most one. It did not cause a build falure though.
*** Bug 355869 has been marked as a duplicate of this bug. ***
Have you guys even tried to report this at icu upstream? IIRC it didn't take ages to get the patch from bug #310297 included upstream.
Weird bug. I would have built libxml2 without icu useflag but STABLE chromium requires it to be set. So the effect is that i cannot simultaniously have wine/openoffice AND chromium on stable system.
(In reply to comment #18) > (In reply to comment #17) > > OK. Considering the number of >5 year old open bug reports in icu trac, > expecting a quick ack from icu developers - without which you will not commit > patches - is clearly unrealistic. So for all intents and purposes, this bug > will not be fixed on the icu end of things. I'm not sure that's fair. I watch this list, and there are a number of fixes which have gone in- especially when an upstream bug is filed with a patch. 354745 doesn't have a ticket filed upstream, and it wasn't clear that it was actually an ICU bug. You can use the format " GentooBug:354745 " in ICU's system to link back here. I'm still trying to get my head around the exact issue. I've installed a gentoo environment as a result of tracking down different bugs on this list, but I haven't had a chance to look at this yet. re #31 Lars: thanks. We do try. Steven R. Loomis, tech lead, ICU for C/C++
please note, this isnt a Gentoo specific issue. you should be able to see the same behavior with any distro running glibc-2.13+.
(In reply to comment #34) > please note, this isnt a Gentoo specific issue. you should be able to see the > same behavior with any distro running glibc-2.13+. If the issue is defined as unwanted inclusion of unicode/pwin32.h by unicode/umachine.h on non-Windows systems, then it is not related to new glibc. unicode/pwin32.h conflicts with sys/types.h of even significantly older glibc versions. The conflict wasn't noticeable previously, because libxml2 wasn't containing support for ICU.
I couldn't reproduce this by emerging icu (4.6) and then wine. ( x86_64 under vmware) The environment of the original test case didn't make sense to me- why would you include pwin32.h for a gentoo compilation? (In reply to comment #35) > (In reply to comment #34) > > please note, this isnt a Gentoo specific issue. you should be able to see the > > same behavior with any distro running glibc-2.13+. > > If the issue is defined as unwanted inclusion of unicode/pwin32.h by > unicode/umachine.h on non-Windows systems, then it is not related to new glibc. > unicode/pwin32.h conflicts with sys/types.h of even significantly older glibc > versions. The conflict wasn't noticeable previously, because libxml2 wasn't > containing support for ICU. >
(In reply to comment #36) > I couldn't reproduce this by emerging icu (4.6) and then wine. ( x86_64 > under vmware) > > The environment of the original test case didn't make sense to me- why would > you include pwin32.h for a gentoo compilation? I just tried wine again and it still fails. Do you have the icu and xml USE flags set? USE=xml emerge -pv1 dev-libs/icu dev-libs/libxml2 dev-libs/libxslt app-emulation/wine These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/icu-4.6 USE="doc examples -debug -static-libs" 0 kB [ebuild R ] dev-libs/libxml2-2.7.8 USE="doc examples icu ipv6 python readline test -debug" 0 kB [ebuild R ] dev-libs/libxslt-1.1.26 USE="crypt python -debug" 0 kB [ebuild R ] app-emulation/wine-1.3.14 USE="X alsa cups dbus fontconfig gecko gphoto2 gsm jpeg lcms ldap mp3 nas ncurses openal opengl oss perl png samba scanner ssl test threads truetype win32 win64 xcomposite xinerama xml* -capi -custom-cflags (-esd) -gnutls (-gstreamer) (-hal) -jack (-nls) -pulseaudio" 0 kB
(In reply to comment #36) > I couldn't reproduce this by emerging icu (4.6) and then wine. ( x86_64 > under vmware) The environment involves (1) icu-4.6; (2) libxml2-2.7.8 configured with --with-icu; (3) wine configured with --with-xml --with-xslt > The environment of the original test case didn't make sense to me- why would > you include pwin32.h for a gentoo compilation? Wine uses libxml/parser.h from libxml2. libxml/parser.h pulls in libxml/encoding.h. Since libxml2 is built with icu support, libxml/encoding.h pulls in unicode/ucnv.h from icu. ucnv.h pulls in ucnv_err.h, which pulls in utypes.h, which pulls in umachine.h. And umachine.h pulls in pwin32.h when WIN32, _WIN32, WIN64, or _WIN64 are defined and __MINGW32__ and CYGWINMSVC are not defined.
(In reply to comment #37) and (In reply to comment #38) Thanks. That actually fails for me, in the expected way.
*** Bug 357185 has been marked as a duplicate of this bug. ***
*** Bug 357355 has been marked as a duplicate of this bug. ***
The problem seems to be fixed in wine 1.3.15 : msxml3 fails to build when libxml2 is built with +icu useflag : http://bugs.winehq.org/show_bug.cgi?id=26228 > > Try wine from git, libxml3 includes were reorganised recently, > probably to solve this issue > > wine from git compiles fine.
*** Bug 357471 has been marked as a duplicate of this bug. ***
It's not really fixed, more like hacked around. See http://source.winehq.org/git/wine.git/?a=commit;h=a1c8f6df847382336b1fc55f4e46d4cd5b58d1b9 by changing the order of includes wine stepped around the problem.
i'm not buying it
Is there an ebuild of Wine 1.3.15?
(In reply to comment #46) > Is there an ebuild of Wine 1.3.15? > Yah its in the tree and appears to work for me.
(In reply to comment #47) > (In reply to comment #46) > > Is there an ebuild of Wine 1.3.15? > > > > Yah its in the tree and appears to work for me. > Cool, it's there now. Wasn't when I posted this. It compiled, and worked for me.
*** Bug 358719 has been marked as a duplicate of this bug. ***
wine-1.2.1 fails this way for me on amd64, and wine-1.3.15 compiles fine. Should we stabilize >=wine-1.3.15?
I have the same results as comment #50, although I just compiled wine -1.3.18 with no problem. I haven't used it much, but it seems to work fine.
wine 1.3.19 fails to build with the specified error described in this bug: x86_64-pc-linux-gnu-gcc -c -I/var/tmp/portage/app-emulation/wine-1.3.19/work/wine-1.3.19/dlls/msxml3 -I. -I/var/tmp/port age/app-emulation/wine-1.3.19/work/wine-1.3.19/include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wst rict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -march=core2 -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURC E=0 -o xslpattern.tab.o xslpattern.tab.c In file included from /usr/include/unicode/umachine.h:50, from /usr/include/unicode/utypes.h:36, from /usr/include/unicode/ucnv_err.h:86, from /usr/include/unicode/ucnv.h:50, from /usr/include/libxml2/libxml/encoding.h:31, from /usr/include/libxml2/libxml/parser.h:807, from /usr/include/libxml2/libxml/globals.h:18, from /usr/include/libxml2/libxml/threads.h:35, from /usr/include/libxml2/libxml/xmlmemory.h:218, from /usr/include/libxml2/libxml/tree.h:1248, from /var/tmp/portage/app-emulation/wine-1.3.19/work/wine-1.3.19/dlls/msxml3/xslpattern.h:32, from /var/tmp/portage/app-emulation/wine-1.3.19/work/wine-1.3.19/dlls/msxml3/xslpattern.l:29: /usr/include/unicode/pwin32.h:152: error: conflicting types for ‘int64_t’ /usr/include/sys/types.h:198: note: previous declaration of ‘int64_t’ was here
*** Bug 366785 has been marked as a duplicate of this bug. ***
3 monthes past, same error, wine-1.3.19, definitely there is something wrong in this world :(
*** Bug 366877 has been marked as a duplicate of this bug. ***
(In reply to comment #52) > wine 1.3.19 fails to build with the specified error described in this bug: ... > /usr/include/unicode/pwin32.h:152: error: conflicting types for ‘int64_t’ > /usr/include/sys/types.h:198: note: previous declaration of ‘int64_t’ was here I haven't had time to look at this again in the time leading up to ICU 4.8 (GA end of month) in trying to get on track for that release. Does anyone have a non-hack suggestion for a patch to ICU? I'm still not quite wrapping my brain (user error) around the environment.
(In reply to comment #56) > (In reply to comment #52) > > wine 1.3.19 fails to build with the specified error described in this bug: ... > > /usr/include/unicode/pwin32.h:152: error: conflicting types for ‘int64_t’ > > /usr/include/sys/types.h:198: note: previous declaration of ‘int64_t’ was here > > I haven't had time to look at this again in the time leading up to ICU 4.8 (GA > end of month) in trying to get on track for that release. > > Does anyone have a non-hack suggestion for a patch to ICU? I'm still not quite > wrapping my brain (user error) around the environment. Is the solution in comment #12 (treating __WINESRC__ like __MINGW32__) too hackish?
*** Bug 366895 has been marked as a duplicate of this bug. ***
*** Bug 366951 has been marked as a duplicate of this bug. ***
*** Bug 367005 has been marked as a duplicate of this bug. ***
Increasing priority since stable is broken for a long time and looks like testing if broken again
Probably the following commit should be backported: http://source.winehq.org/git/wine.git/commitdiff/7e894f8741dbe56680e42c95500fee44bb43ce67
(In reply to comment #62) > Probably the following commit should be backported: > http://source.winehq.org/git/wine.git/commitdiff/7e894f8741dbe56680e42c95500fee44bb43ce67 Honestly, can't icu and wine devs hash it out who's exactly breaking things ? Either icu headers need to be adjusted to the way wine sets those defines, or winegcc needs to be sanitized in this regard.
(In reply to comment #60) > *** Bug 367005 has been marked as a duplicate of this bug. *** Since I was redirected here through the duplicate I filed, I'll add this link here: http://forums.gentoo.org/viewtopic-p-6683879.html along with my original comment. Once read can someone tell me why disabling the winarch use flags works around this bug? Comment: It seems that disabling the winarch(win32/win64) flag would do the trick according to the forum post, but this change isn't noted in the Changelog at WineHQ, therefore I assume this is a valid bug, as all previous versions allow both flags to be set.
including headers should not require fore knowledge and/or explicit ordering
*** Bug 367081 has been marked as a duplicate of this bug. ***
*** Bug 367439 has been marked as a duplicate of this bug. ***
Seems like the simplest solution is to just emerge this with -win64 use. I'm not sure of how many 64bit programs anyone would actually use with wine anyway.
What's wrong with the header wrapping script I posted? It is a hack, but it's non-invasive, low maintenance and reliably solves the problem.
(In reply to comment #57) > (In reply to comment #56) > > (In reply to comment #52) > > > wine 1.3.19 fails to build with the specified error described in this bug: ... > > > /usr/include/unicode/pwin32.h:152: error: conflicting types for ‘int64_t’ > > > /usr/include/sys/types.h:198: note: previous declaration of ‘int64_t’ was here > > > > I haven't had time to look at this again in the time leading up to ICU 4.8 (GA > > end of month) in trying to get on track for that release. > > > > Does anyone have a non-hack suggestion for a patch to ICU? I'm still not quite > > wrapping my brain (user error) around the environment. > > Is the solution in comment #12 (treating __WINESRC__ like __MINGW32__) too > hackish? Thought I replied here, but I don't see it- that solution does look promising. (In reply to comment #63) > Honestly, can't icu and wine devs hash it out who's exactly breaking things ? That's what I'm attempting to do here... (In reply to comment #69) > What's wrong with the header wrapping script I posted? It is a hack If the upstream is broken, it should be fixed not hacked around. (And, I think there still isn't a bug filed there).
(In reply to comment #70) > If the upstream is broken, it should be fixed not hacked around. (And, I think > there still isn't a bug filed there). A proper fix would be to update the ICU build system such that it will, at configure/install time, hardcode the determined operating system into the headers which it installs, rather than having the installed headers do the determination all over again. For example, generate a file "icuconfig.h" with contents, for example: #define ICU_PLATFORM_WIN32 The other ICU includes would than #include "icoconfig.h", and convert tests from #ifdef _WIN32 to #ifdef ICU_PLATFORM_WIN32 .
(In reply to comment #71) > (In reply to comment #70) > > If the upstream is broken, it should be fixed not hacked around. (And, I think > > there still isn't a bug filed there). > > A proper fix would be to update the ICU build system such that it will, at > configure/install time, hardcode the determined operating system into the > headers which it installs, rather than having the installed headers do the > determination all over again. > > For example, generate a file "icuconfig.h" with contents, for example: > #define ICU_PLATFORM_WIN32 > > The other ICU includes would than #include "icoconfig.h", and convert tests > from > > #ifdef _WIN32 > > to > > #ifdef ICU_PLATFORM_WIN32 ICU does create a generated file, platform.h. The problem is trying to understand how to best detect this specific environment. It seems like a good suggestion to create an 'aggregate' symbol of some sort.
(In reply to comment #72) > ICU does create a generated file, platform.h. The problem is trying to > understand how to best detect this specific environment. It seems like a good > suggestion to create an 'aggregate' symbol of some sort. Do the same #ifdef checks at configure time using the preprocessor. I believe most build systems already provide such functionality. Regardless, I present one way to determine macro values. A test for _WIN32: #ifndef _WIN32 MACRO_UNDEFINED #else MACRO_VALUE_START _WIN32 MACRO_VALUE_END #endif Preprocessing this file (e.g. gcc -E file.h) results in this on Windows (excluding some comments): MACRO_VALUE_START 1 MACRO_VALUE_END While on Linux it results in: MACRO_UNDEFINED Therefore, is possible to determine from the result whether a macro is defined, and what its value is.
*** Bug 368701 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27341
bug report at the icu bugtracker: http://bugs.icu-project.org/trac/ticket/8609
*** Bug 369031 has been marked as a duplicate of this bug. ***
*** Bug 373853 has been marked as a duplicate of this bug. ***
*** Bug 374227 has been marked as a duplicate of this bug. ***
*** Bug 374483 has been marked as a duplicate of this bug. ***
*** Bug 374679 has been marked as a duplicate of this bug. ***
My bug report was marked as a dupe of this one, but I can add some information that's possibly useful. As far as WINE, I was updating from 1.2.1 (which compiled fine) to 1.2.3 (which didn't), with (AFAIR) the same USE flag set. I wish I knew how long it had been between updates; it'd be easier to know which other package updating might have led to the conflict.
*** Bug 375017 has been marked as a duplicate of this bug. ***
wine people, please backport the wine patch from 1.3.x series to let stable version compile... we have been living with broken compilation of stable wine for months Thanks
Other option would be to stabilize a wine-1.3.x version :-/
(In reply to comment #85) > Other option would be to stabilize a wine-1.3.x version :-/ The 1.3.x series is the development series so is unstable by definition, but I guess some specific releases in that series are more stable than others!
Can a decision be taken to fix stable wine version? (either backporting or stabilizing a 1.3 release, but stop having stable version broken for months)
Steven, any updates from ICU upstream? I have tried to search for fixes in icu in different distributions without success :-(
(In reply to comment #88) > Steven, any updates from ICU upstream? I have tried to search for fixes in icu > in different distributions without success :-( #8609 has already been accepted and is scheduled for the ICU 49.1 milestone, scheduled for Sept 28. ICU platform.h has already been greatly simplified.
Could it be backported for 4.8.x to allow us to get a fixed version sooner? Thanks again
(In reply to comment #90) > Could it be backported for 4.8.x to allow us to get a fixed version sooner? That specific change, no, but the fix may be portable. Please wait until the bug is fixed.
This bug is pathetic. Big stable package in a major distribution is waiting broken for months with a patch provided. Gentoo's dead.
this isnt the place to complain. go use the forums/blogs/something else.
*** Bug 380427 has been marked as a duplicate of this bug. ***
PHP compiles fine, so we're out of here.
(In reply to comment #93) > this isnt the place to complain. go use the forums/blogs/something else. Could it be possibly masked in the meantime? IMHO this could help so as to avoid users running into this every time they do world update.
i think we've been waiting on the direction upstream wants to take things, and then adding that to our ebuilds
The worrying thing is that the upstream fix is not due (ICU 49.1 milestone) for 7 months!
you missed the nuance of my comment. we're not waiting for upstream to make a new release, we're waiting to see *how* they're fixing things. once we have that, we can add a new ebuild with the backported fix.
(In reply to comment #98) > The worrying thing is that the upstream fix is not due (ICU 49.1 milestone) for > 7 months! FYI: ICU 49.1 is not a milestone, it's the internal version number of GA for 49, due 2012-March (see icu-project.org)
*** Bug 397993 has been marked as a duplicate of this bug. ***
anyone able to test milestone 2? pwin32.h as a file is no more.. http://site.icu-project.org/download/49milestone
Oh wonderful--> ExtensionSubtables.cpp:32:31: warning: dereferencing type-punned pointer will break strict aliasing rules but if you set CFLAGS="${CFLAGS} -fno-strict-aliasing" it's totally ignored and uninstalling it would mean uninstalling possibly--- david@penguin4 ~ $ equery depends icu * These packages depend on icu: app-misc/tracker-0.12.10 (>=dev-libs/icu-4) app-office/libreoffice-bin-3.5.2.2 (~dev-libs/icu-4.8.1.1) (>=dev-libs/icu-4.8.1.1) dev-db/sqlite-3.7.11 (icu ? dev-libs/icu) dev-libs/beecrypt-4.2.1 (cxx ? >=dev-libs/icu-2.8) dev-libs/boost-1.49.0-r1 (icu ? >=dev-libs/icu-3.3) dev-libs/libxml2-2.7.8-r5 (icu ? dev-libs/icu) dev-tex/bibtexu-3.71_p20110705 (>=dev-libs/icu-4.4) media-libs/raptor-2.0.7 (unicode ? dev-libs/icu) net-libs/webkit-gtk-1.8.1-r301 (>=dev-libs/icu-3.8.1-r1) net-nds/openldap-2.4.30 (icu ? dev-libs/icu)
(In reply to comment #102) > anyone able to test milestone 2? pwin32.h as a file is no more.. > http://site.icu-project.org/download/49milestone Anyone able to test ICU 49? http://bugs.icu-project.org/trac/ticket/8609#comment:4
(In reply to comment #103) > Oh wonderful--> > > ExtensionSubtables.cpp:32:31: warning: dereferencing type-punned pointer > will break strict aliasing rules fixed in http://bugs.icu-project.org/trac/ticket/8310 and in any event unrelated to this ticket.
(In reply to comment #99) > you missed the nuance of my comment. we're not waiting for upstream to make > a new release, we're waiting to see *how* they're fixing things. once we > have that, we can add a new ebuild with the backported fix. and, we (the upstream) have still not heard how the recent (i.e. last year) changes affect things. I'm sorry but this is not an easy configuration to reproduce. 50 milestone is out now: http://site.icu-project.org/download/50milestone
I am closing this bug since the problem no longer occurs.
