webkit-gtk3 @ 2.4.11_4+video build fails with 'CSSGrammar.hpp' file not found

[hapaguy (Brian Kurt Fujikawa)]

I am running macOS 10.15.6, using Xcode 11.6, and MacPorts 2.6.3.

% sudo port -sv upgrade webkit-gtk3

fails with

:info:build DerivedSources/WebCore/CSSGrammar.cpp:160:10: fatal error: 'CSSGrammar.hpp' file not found
:error:build Failed to build webkit-gtk3: command execution failed

I confirmed that there is no file CSSGrammar.hpp in

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_webkit-gtk/webkit-gtk3/work/webkitgtk-2.4.11/DerivedSources/WebCore/

But, there is a CSSGrammar.h.

I have attached the main.log.

[hapaguy (Brian Kurt Fujikawa)]

zip'd main.log (original 12.9 MB > 10.0 MB)

[ryandesign (Ryan Carsten Schmidt)]

We see the same problem on the MacPorts build servers.

This port is years out of date. The current version is 2.28.4. There is no maintainer looking after this port. Maybe updating to the latest version would help with this problem, if someone wants to try doing that. Be warned that webkit is a very large and complex piece of software and it may require significant effort to update this.

[yaseppochi (Stephen J. Turnbull)]

I am not willing to do the work of updating the port, but I got a build with the following procedure (this can probably be optimized in several ways, but it worked to the point of successfully upgrading -- not sure if the packages that use webkit-gtk work, though).

sudo port clean webkit-gtk
sudo port fetch webkit-gtk
sudo port extract webkit-gtk
sudo port configure webkit-gtk
cd /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/DerivedSources/WebCore/
ln -s CSSGrammar.h CSSGrammar.hpp
ln -s XPathGrammar.h XPathGrammar.hpp
sudo port build webkit-gtk
sudo port upgrade webkit-gtk

This procedure is offered with NO WARRANTY blah blah blah ;-)

[hapaguy (Brian Kurt Fujikawa)]

I suspect that this issue is related to a similar issue with qt5-qtwebengine (#60978), which is caused by a bison 3.7 bug (comment:ticket:60978:3).

[rlhamil]

Replying to hapaguy:

I suspect that this issue is related to a similar issue with qt5-qtwebengine (#60978), which is caused by a bison 3.7 bug (comment:ticket:60978:3).

I re-installed the older bison @3.6.4_0, and webkit-gtk3 built just fine with that, and subsequently deactivating it and reactivating the current bison didn't break anything either. So that probably confirms the general notion that something different about bison 3.7 is the problem.

[ewenmcneill (Ewen McNeill)]

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 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@ashram:~$ port installed | grep webkit-gtk
  webkit-gtk @2.4.11_2+video
  webkit-gtk @2.4.11_3+video (active)
ewen@ashram:~$ sudo port deactivate 'webkit-gtk'
--->  Deactivating webkit-gtk @2.4.11_3+video
--->  Cleaning webkit-gtk
ewen@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@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; ​Bison 3.7 was released 2020-07-23 (ie, about a month ago). And ​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, ​the build for macOS 10.14 has ​webkit-gtk build warnings which look very similar to what I'm seeing here as warnings during build attempts.

Ewen

ewen@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@ashram:~$ 

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

[kencu (Ken)]

Replying to ryandesign:

This port is years out of date. The current version is 2.28.4. There is no maintainer looking after this port. Maybe updating to the latest version would help with this problem, if someone wants to try doing that. Be warned that webkit is a very large and complex piece of software and it may require significant effort to update this.

Make sure we're talking about the right port.

Our webkit2-gtk port is the mainstay for webkit-gtk on MacPorts, and it's at 2.28.2 just now. There is a new 2.30.1 version that is out now, that I will probably get around to soon.

We also have all these:

webkit-gtk
webkit-gtk-2.0
webkit-gtk3
webkit-gtk3-2.0

all of which should be retired as soon as possible I think, and none of which should be used for any new project. All of them are ancient, out of date, unmaintained dinosaurs that probably just confuse people who should be directed to our (quite current, and only available for MacOS via MacPorts) webkit2-gtk and webkit2-gtk-devel.

webkit2-gtk-devel is not being updated the way a *-devel port might -- it's just too damned much work, to be honest -- but we keep it around for testing wreckage before we roll out webkit2-gtk updates, if nothing else.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #61355.