[MacPorts] #60977: webkit-gtk3 @ 2.4.11_4+video build fails with 'CSSGrammar.hpp' file not found

MacPorts noreply at macports.org
Fri Aug 21 02:28:35 UTC 2020


#60977: webkit-gtk3 @ 2.4.11_4+video build fails with 'CSSGrammar.hpp' file not
found
--------------------------+--------------------
  Reporter:  hapaguy      |      Owner:  (none)
      Type:  defect       |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  webkit-gtk3  |
--------------------------+--------------------

Comment (by ewenmcneill):

 I also had this problem (re)building webkit-gtk on macOS 10.14, when it
 got flagged as needing a rebuild after upgrading something else; from the
 comments above it seems like it's affecting both webkit-gtk3 ''and''
 webkit-gtk.  (I do also have webkit2-gtk installed, which so far seems to
 rebuild okay; but not webkit3-gtk.)

 After a bunch of trying to get it to build following the suggestion from
 [https://trac.macports.org/ticket/60977#comment:4 comment 4 above], I
 realised I probably didn't even need the port any longer, due to #52398.
 There's not much that depends on webkit-gtk any longer, and AFAICT it's
 actually only a couple of packages now, which I don't have installed.

 So I deactivated webkit-gtk and moved on to the next package needing
 rebuilding:

 {{{
 ewen at ashram:~$ port installed | grep webkit-gtk
   webkit-gtk @2.4.11_2+video
   webkit-gtk @2.4.11_3+video (active)
 ewen at ashram:~$ sudo port deactivate 'webkit-gtk'
 --->  Deactivating webkit-gtk @2.4.11_3+video
 --->  Cleaning webkit-gtk
 ewen at ashram:~$ port installed | grep webkit
   webkit-gtk @2.4.11_2+video
   webkit-gtk @2.4.11_3+video
   webkit2-gtk @2.26.2_1+minibrowser+x11
   webkit2-gtk @2.28.2_0+minibrowser+x11
   webkit2-gtk @2.28.2_1+minibrowser+x11 (active)
 ewen at ashram:~$
 }}}

 (Interestingly once I did that, qt5-qtbase which was previously flagged as
 needing rebuilding no longer needed rebuilding, so possibly webkit-gtk was
 the cause of link issues in both cases?)

 After I did that, I was able to get everything else upgraded (including
 dia rebuilt) without problems (and dia seems to start okay).

 In case anyone wants to try to get it building, note that I found the two
 "ln -s" commands also needed "sudo" to work ''and'' I had to redo them
 (from another window) after the "sudo port build" started, as the pre-made
 links seemed to get removed as the DerivedSources directory got populated.
 But even then the build failed for me, apparently due to Bison induced
 changes, eg:

 {{{
 :info:build DerivedSources/WebCore/CSSGrammar.cpp:1756:37: error: unknown
 type name 'YYSTYPE'
 :info:build             yysymbol_kind_t yykind, YYSTYPE *yyvaluep,
 CSSParser* parser)
 :info:build                                     ^
 :info:build DerivedSources/WebCore/CSSGrammar.cpp:2068:26: error: unknown
 type name 'YYSTYPE'
 :info:build YY_INITIAL_VALUE (static YYSTYPE yyval_default;)
 :info:build                          ^
 :info:build DerivedSources/WebCore/CSSGrammar.cpp:2069:1: error: unknown
 type name 'YYSTYPE'
 :info:build YYSTYPE yylval YY_INITIAL_VALUE (= yyval_default);
 :info:build ^
 }}}

 So downgrading Bison for the build is probably a simpler work around for
 now, if you do need webkit-gtk.  But it'd be worth checking if you do
 still need it.

 (I had Bison 3.7.1 active when testing, which seems to be the latest
 upstream release; [https://lists.gnu.org/archive/html/info-
 gnu/2020-07/msg00006.html Bison 3.7 was released 2020-07-23] (ie, about a
 month ago).  And [https://lists.gnu.org/archive/html/info-
 gnu/2020-08/msg00000.html Bison 3.7.1 was released 2020-08-02], apparently
 "This bug fix release addresses portability issues of Bison 3.7, including
 with versions of libtextstyle." but clearly not these webkit issues.)

 Of note, there are also two configure warnings of replaces that no longer
 match; I think those are unrelated to the build failing.

 And there are also lots of C++ compile warnings (due to changing
 compiler/code assumptions around C++ NULL handling); eg,
 [https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/65153
 the build for macOS 10.14] has
 [https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/65153/steps
 /install-port/logs/warnings%20%282719%29 webkit-gtk build warnings] which
 look very similar to what I'm seeing here as warnings during build
 attempts.

 Ewen

 {{{
 ewen at ashram:~$ sudo port configure webkit-gtk
 --->  Computing dependencies for webkit-gtk
 --->  Applying patches to webkit-gtk
 Warning: reinplace s/def __APPLE__/ 0/ didn't change anything in
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
 .org_release_tarballs_ports_www_webkit-gtk/webkit-
 gtk/work/webkitgtk-2.4.11/Source/JavaScriptCore/API/WebKitAvailability.h
 Warning: reinplace s:-stdlib=libstdc++:: didn't change anything in
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
 .org_release_tarballs_ports_www_webkit-gtk/webkit-
 gtk/work/webkitgtk-2.4.11/Source/autotools/SetupCompilerFlags.m4
 --->  Configuring webkit-gtk
 ewen at ashram:~$
 }}}

 {{{
 ewen at ashram:~$ port echo rdepends:webkit-gtk
 bibledit
 uzbl
 ewen at ashram:~$ port installed | grep uzbl
 ewen at ashram:~$ port installed | grep bibledit
 ewen at ashram:~$
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/60977#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list