Bug 93487 – [CMAKE][EFL] Fix build break with --tiled-backing-store

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit EFL

[Ryuan Choi]

I got below compile errors when compiled with --tiled-backing-store.

CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yy_flush_buffer(yy_buffer_state*, void*)':
glslang_lex.cpp:(.text+0x2e0): multiple definition of `yy_flush_buffer(yy_buffer_state*, void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x2e0): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_extra(void*)':
glslang_lex.cpp:(.text+0x360): multiple definition of `yyget_extra(void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x360): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_lineno(void*)':
glslang_lex.cpp:(.text+0x370): multiple definition of `yyget_lineno(void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x370): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_column(void*)':
glslang_lex.cpp:(.text+0x390): multiple definition of `yyget_column(void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x390): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_in(void*)':
glslang_lex.cpp:(.text+0x3b0): multiple definition of `yyget_in(void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x3b0): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_out(void*)':
glslang_lex.cpp:(.text+0x3c0): multiple definition of `yyget_out(void*)'
CMakeFiles/webcore_efl.dir/__/__/DerivedSources/WebCore/glslang.cpp.o:glslang.cpp:(.text+0x3c0): first defined here
CMakeFiles/webcore_efl.dir/__/ThirdParty/ANGLE/src/compiler/glslang_lex.cpp.o: In function `yyget_leng(void*)':
glslang_lex.cpp:(.text+0x3d0): multiple definition of `yyget_leng(void*)'

I checked that other ports does not include glslang_lex.cpp.

[Ryuan Choi]

Created attachment 157227 [details]
Patch

[Raphael Kubo da Costa (:rakuco)]

Does the _tab.cpp file also cause problems? Do you know whether it makes sense to generate these files instead of using the generated ones from ANGLE?

[Ryuan Choi]

(In reply to comment #2)
> Does the _tab.cpp file also cause problems? Do you know whether it makes sense to generate these files instead of using the generated ones from ANGLE?

Sorry, I cut the log because it is too long.

_tab.cpp also have same issue.

I don't know ANGLE enough, but I choosed generated one because 
  1) generated one looks better although almost changes are minor (such as size_t vs int)
  2) other ports also used generated one.

[Raphael Kubo da Costa (:rakuco)]

Right. svn blame tells me that the lex and tab.cpp files were added by Joshua Netterfield for the BlackBerry port, so I'm CC'ing both him and Rob in case they have anything to say.

[Joshua Netterfield]

We also wanted to use the generated files, but it doesn't compile with certain versions of Bison. I'm noticing that upstream both versions are present (probably due to a merge failure on my end). Perhaps it would be best to have the generated files in PlatformEfl.cmake and the non-generated files in PlatformBlackBerry.cmake?

[Ryuan Choi]

(In reply to comment #5)
> We also wanted to use the generated files, but it doesn't compile with certain versions of Bison. I'm noticing that upstream both versions are present (probably due to a merge failure on my end). Perhaps it would be best to have the generated files in PlatformEfl.cmake and the non-generated files in PlatformBlackBerry.cmake?

Can I know which version of BISON has problem?

I think that this is not port specific issue.
So, what do you think about checking bison version which we has issue like below?

IF (BISON_VERSION EQUAL "specific version")
    # 
ELSE ()
    # use generated one
ENDIF ()

[Joshua Netterfield]

Yes, that sounds good. We had trouble with version 2.5 on mac.

[Ryuan Choi]

Created attachment 157567 [details]
Patch

[Ryuan Choi]

(In reply to comment #7)
> Yes, that sounds good. We had trouble with version 2.5 on mac.

Ok, updated.
Could you test whether it works for you?

Thank you.

[WebKit Review Bot]

Comment on attachment 157567 [details]
Patch

Clearing flags on attachment: 157567

Committed r125496: <http://trac.webkit.org/changeset/125496>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.