Bug 94849

Summary: [GTK] Compiling with --disable-blob fails with undefined symbol
Product: WebKit Reporter: Philip Chimento <philip.chimento>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Minor CC: pnormand, webkit.review.bot, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.6   
Attachments:
Description Flags
Patch that fixes the problem
xan.lopez: review-
Sample patch none

Description Philip Chimento 2012-08-23 14:14:57 PDT
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.)
Comment 1 WebKit Review Bot 2012-08-23 14:18:00 PDT
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.
Comment 2 Philippe Normand 2012-08-24 06:24:35 PDT

*** This bug has been marked as a duplicate of bug 94919 ***
Comment 3 Xan Lopez 2012-08-24 08:04:59 PDT
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.
Comment 4 Xan Lopez 2012-08-24 08:11:02 PDT
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.
Comment 5 Philip Chimento 2012-08-25 00:35:56 PDT
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?
Comment 6 Xan Lopez 2012-08-25 03:09:28 PDT
(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.
Comment 7 Philip Chimento 2012-08-25 04:50:13 PDT
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?
Comment 8 Philip Chimento 2015-01-02 20:23:11 PST
I don't believe this is a problem anymore.