Bug 94849 – [GTK] Compiling with --disable-blob fails with undefined symbol

• Component: WebKitGTK
• Status: RESOLVED INVALID

[Philip Chimento]

Created attachment 160238 [details]
Patch that fixes the problem

Configuring with --disable-blob causes make to fail with an undefined symbol. Here is a patch (based on WebKitGTK 1.8.3) that fixes it.

(This would seem to imply that bug #44867 has been fixed somewhere along the line.)

[WebKit Review Bot]

Attachment 160238 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files']" exit_code: 1
Total errors found: 0 in 0 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Philippe Normand]

*** This bug has been marked as a duplicate of bug 94919 ***

[Xan Lopez]

This is not really the same issue than bug 94919, but I don't think that's the right patch either. Basically the method should be a non-op when the feature is disabled, so move the #ifdefs into it I'd say.

[Xan Lopez]

Comment on attachment 160238 [details]
Patch that fixes the problem

r- per previous comment. Basically I think this should take into account the ENABLE features in WebKit (see how the bindings are generated), but the compat. method should always be present to not break API (and thus, the WebKitDOMBlob type should always be present too). I believe this is how we do the other stuff.

[Philip Chimento]

So you're saying that rather than simply moving the #ifdef's inside the function body, I should make sure a stub WebKitDOMBlob type is defined? Or simply remove the #ifdef's from WebKitDOMBlob?

[Xan Lopez]

(In reply to comment #5)
> So you're saying that rather than simply moving the #ifdef's inside the function body, I should make sure a stub WebKitDOMBlob type is defined? Or simply remove the #ifdef's from WebKitDOMBlob?

I'm saying that I think the right fix is to change the WebKitDOMBlob creation so that it respects the ENABLE(BLOB) flags, like other GObject DOM types do (see for instance WebKitDOMTimeRanges). We cannot remove the methods themselves randomly, otherwise we'd break API. If we do that I think the code in WebKitDOMCustom would probably just remain as is, being a no-op.

[Philip Chimento]

Created attachment 160562 [details]
Sample patch

So, you're saying all it should take is a Conditional=BLOB in Blob.idl, like the attached patch (WARNING- not tested, don't commit.) Does that mean I should remove the #if !ENABLE(BLOB) around slice() and webkitSlice() in the IDL file?

Is this the way I should be tackling the related bugs I filed, #94851 and #94853?

[Philip Chimento]

I don't believe this is a problem anymore.