Summary: | [harfbuzz] WebKit fails to build with MinGW compiler because of invalid cast in HarfBuzzShaper.cpp | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | tuxator | ||||||||||||
Component: | Platform | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | commit-queue, darin, dglazkov, d-r, kalevlember, mrobinson, peter+ews, webkit.review.bot | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | Unspecified | ||||||||||||||
OS: | Unspecified | ||||||||||||||
Attachments: |
|
Description
tuxator
2013-01-30 13:19:23 PST
Created attachment 185553 [details]
proposed fix
Created attachment 185739 [details]
Update for directory rename
Comment on attachment 185739 [details] Update for directory rename Attachment 185739 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16266173 Comment on attachment 185739 [details] Update for directory rename Attachment 185739 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16271193 Comment on attachment 185739 [details] Update for directory rename Attachment 185739 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16252352 Created attachment 185745 [details]
don't ommit const
Comment on attachment 185745 [details]
don't ommit const
This kind of cast always makes me nervous.
(In reply to comment #0) > Build dies with the following error > > GEN generate-testwebkitapi-forwarding-headers > GEN DerivedSources/JavaScriptCore/LLIntAssembly.h > offlineasm: Parsing ./Source/JavaScriptCore/llint/LowLevelInterpreter.asm and Programs/LLIntOffsetsExtractor.exe and creating assembly file DerivedSources/JavaScriptCore/LLIntAssembly.h. > offlineasm: No magic values found. Skipping assembly file generation. > make all-am > make[1]: Wejście do katalogu `/home/pawel/src/webkit' > /usr/bin/mkdir -p ./.deps/DerivedSources > CXX Source/WebCore/platform/graphics/harfbuzz/ng/libWebCore_la-HarfBuzzShaper.lo > Source/WebCore/platform/graphics/harfbuzz/ng/HarfBuzzShaper.cpp: In member function 'bool WebCore::HarfBuzzShaper::shapeHarfBuzzRuns(bool)': > Source/WebCore/platform/graphics/harfbuzz/ng/HarfBuzzShaper.cpp:340:138: error: invalid conversion from 'const UChar* {aka const wchar_t*}' to 'const uint16_t* {aka const short unsigned int*}' [-fpermissive] m_normalizedBuffer is declared as follow: OwnArrayPtr<UChar> m_normalizedBuffer; Are you sure you have a correctly sized UChar typedef/declaration on your platform? What configuration are you building? Does it match one of the bots? (In reply to comment #8) > > m_normalizedBuffer is declared as follow: > OwnArrayPtr<UChar> m_normalizedBuffer; > Are you sure you have a correctly sized UChar typedef/declaration on your platform? What configuration are you building? Does it match one of the bots? I try to cross compile WebkitGTK for Windows using MinGW stack, there is no such build bot like that as far as i know. (In reply to comment #9) > (In reply to comment #8) > > > > > m_normalizedBuffer is declared as follow: > > OwnArrayPtr<UChar> m_normalizedBuffer; > > Are you sure you have a correctly sized UChar typedef/declaration on your platform? What configuration are you building? Does it match one of the bots? > > I try to cross compile WebkitGTK for Windows using MinGW stack, there is no such build bot like > that as far as i know. I would try to follow up why UChar/wchar_t is not matching uint16_t in this configuration, maybe there is something wrong with your build configuration of ICU. Comment on attachment 185745 [details]
don't ommit const
Change looks fine. Patch needs a change log.
UChar is always defined as a 16 bit type. Depending on the build configuration, the exact type can vary, but it's always a 16 bit type. In the GTK+/MinGW configuration, the preprocessor magic chooses it to be wchar_t, but only after making sure wchar_t is a 16 bit type. Unfortunately, even though the source and target types are both 16 bit, gcc considers them to be different, so it needs an explicit reinterpret_cast. From Source/JavaScriptCore/icu/unicode/umachine.h: #if U_SIZEOF_WCHAR_T==2 typedef wchar_t UChar; #elif U_GNUC_UTF16_STRING #if defined _GCC_ typedef __CHAR16_TYPE__ char16_t; #endif typedef char16_t UChar; #else typedef uint16_t UChar; #endif Created attachment 203629 [details]
Patch updated with the changelog
Comment on attachment 203629 [details] Patch updated with the changelog View in context: https://bugs.webkit.org/attachment.cgi?id=203629&action=review > Source/WebCore/ChangeLog:10 > + No new tests (OOPS!). You need to remove this line for the patch to pass the tools. Created attachment 203631 [details]
updated
Comment on attachment 203631 [details] updated Clearing flags on attachment: 203631 Committed r151141: <http://trac.webkit.org/changeset/151141> All reviewed patches have been landed. Closing bug. |