<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>147816</bug_id>
          
          <creation_ts>2015-08-09 05:43:12 -0700</creation_ts>
          <short_desc>Enable optimization causes undefined reference error for debug build</short_desc>
          <delta_ts>2015-08-11 09:46:10 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>New Bugs</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>Other</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Ting-Wei Lan">lantw44</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>commit-queue</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1116096</commentid>
    <comment_count>0</comment_count>
    <who name="Ting-Wei Lan">lantw44</who>
    <bug_when>2015-08-09 05:43:12 -0700</bug_when>
    <thetext>We usually disable optimization for debug build, but I hope it doesn&apos;t fail when optimization is enabled. I got these messages when my CXXFLAGS contains -O2:

lib/libjavascriptcoregtk-4.0.so.18.2.4: undefined reference to &apos;JSC::JSCell::inherits(JSC::ClassInfo const*) const&apos;
lib/libjavascriptcoregtk-4.0.so.18.2.4: undefined reference to &apos;JSC::JSCell::structure() const&apos;
../../Source/WebCore/editing/InsertNodeBeforeCommand.cpp:47: error: undefined reference to &apos;WebCore::ContainerNode::renderer() const&apos;

I will attach a patch that add 3 lines of include to fix this problem.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116097</commentid>
    <comment_count>1</comment_count>
      <attachid>258592</attachid>
    <who name="Ting-Wei Lan">lantw44</who>
    <bug_when>2015-08-09 05:47:21 -0700</bug_when>
    <thetext>Created attachment 258592
Fix debug build when optimization is enabled</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116110</commentid>
    <comment_count>2</comment_count>
      <attachid>258592</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2015-08-09 11:42:44 -0700</bug_when>
    <thetext>Comment on attachment 258592
Fix debug build when optimization is enabled

View in context: https://bugs.webkit.org/attachment.cgi?id=258592&amp;action=review

&gt; Source/JavaScriptCore/ChangeLog:3
&gt; +        Fix debug build when optimization is enabled

This patch seems OK to land, however I&apos;m not sure what problem you are solving here. My understanding is that debug build is by definition -O0, and I don&apos;t see why to change that.

If you are trying to enable assertions, that should be done by fixing release build with ASSERT_DISABLED set to 0.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116180</commentid>
    <comment_count>3</comment_count>
    <who name="Ting-Wei Lan">lantw44</who>
    <bug_when>2015-08-10 00:01:21 -0700</bug_when>
    <thetext>Yes, debug build should be -O0, but I think it should not fail just because optimization is accidentally enabled. I found this problem when I forgot to check my CXXFLAGS before starting a build.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116216</commentid>
    <comment_count>4</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2015-08-10 09:00:48 -0700</bug_when>
    <thetext>I can imagine how much time can be wasted on debugging an issue like this, and how annoying that would be.

If this is not a configuration that needs to be built, I think that it&apos;s better to catch that with an explicit compile error, so that it&apos;s easy to detect and fix. What do you think?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116261</commentid>
    <comment_count>5</comment_count>
    <who name="Ting-Wei Lan">lantw44</who>
    <bug_when>2015-08-10 11:24:16 -0700</bug_when>
    <thetext>I think we still need to fix undefined reference problems because they are all caused by assert. Should I change the commit message to &apos;Fix undefined reference errors when assertion is enabled&apos;?

I think we can add some warning messages in a cmake file or commonly-used header, so users can see a lot of warnings. They know they are probably doing wrong things because it is hard to ignore all messages.

I think we can add an error message to stop the build in build-webkit script or other scripts that are not used in building distribution packages. It is possible for users of source-based package managers (ports, pkgsrc, portage) to set CXXFLAGS globally for all packages, and causing build failure is very annoying because it stops building of all packages depending on WebKit. Packages usually use release build, but it is still possible for users to set an option to change it to debug build. (This option is called FULLDEBUG in FreeBSD ports although it seldom works)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116318</commentid>
    <comment_count>6</comment_count>
      <attachid>258592</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2015-08-10 13:44:43 -0700</bug_when>
    <thetext>Comment on attachment 258592
Fix debug build when optimization is enabled

Are you saying that exactly the same issue happens in a release build with ASSERT_DISABLED set to 0? Then yes, I agree that this should be done.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116499</commentid>
    <comment_count>7</comment_count>
    <who name="Ting-Wei Lan">lantw44</who>
    <bug_when>2015-08-10 23:41:36 -0700</bug_when>
    <thetext>I think it should happen in release build with ASSERT_DISABLED=0 because all these problems are caused by function calls done in assert, but I cannot test it because it doesn&apos;t build:

../../Source/WTF/wtf/dtoa/bignum.cc:772:30: error: use of undeclared identifier &apos;a&apos;
        ASSERT(Bignum::Equal(a, *this));
                             ^
../../Source/WTF/wtf/Assertions.h:235:8: note: expanded from macro &apos;ASSERT&apos;
    (!(assertion) ? \
       ^
1 error generated.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116551</commentid>
    <comment_count>8</comment_count>
      <attachid>258592</attachid>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2015-08-11 09:46:07 -0700</bug_when>
    <thetext>Comment on attachment 258592
Fix debug build when optimization is enabled

Clearing flags on attachment: 258592

Committed r188256: &lt;http://trac.webkit.org/changeset/188256&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1116552</commentid>
    <comment_count>9</comment_count>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2015-08-11 09:46:10 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>258592</attachid>
            <date>2015-08-09 05:47:21 -0700</date>
            <delta_ts>2015-08-11 09:46:07 -0700</delta_ts>
            <desc>Fix debug build when optimization is enabled</desc>
            <filename>bug-147816-20150809124708.patch</filename>
            <type>text/plain</type>
            <size>2846</size>
            <attacher name="Ting-Wei Lan">lantw44</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTg4MTkzCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw
dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA3
YmI2NzJhNDEyMjAyNzVhY2UyZGU3NDllOTZlZDc4ZjFlNGQ0MTA1Li4yMjQ5ZmZjNDAwYmViYjIz
MTRiNGE4MTg3NWQyYWY1NWU4MjhlNDlhIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv
cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs
MyArMSwxMyBAQAorMjAxNS0wOC0wOCAgVGluZy1XZWkgTGFuICA8bGFudHc0NEBnbWFpbC5jb20+
CisKKyAgICAgICAgRml4IGRlYnVnIGJ1aWxkIHdoZW4gb3B0aW1pemF0aW9uIGlzIGVuYWJsZWQK
KyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE0NzgxNgor
CisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogbGxpbnQv
TExJbnRFbnRyeXBvaW50LmNwcDoKKyAgICAgICAgKiBydW50aW1lL0Z1bmN0aW9uRXhlY3V0YWJs
ZUR1bXAuY3BwOgorCiAyMDE1LTA4LTA3ICBHeXV5b3VuZyBLaW0gIDxneXV5b3VuZy5raW1Ad2Vi
a2l0Lm9yZz4KIAogICAgICAgICBSZWR1Y2UgdXNlcyBvZiBQYXNzUmVmUHRyIGluIGJpbmRpbmdz
CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9D
aGFuZ2VMb2cKaW5kZXggNDNjOWZhNWJkOTk2NWYzMWNjM2UxZDgwZTA1MzA5MmZkNGYyMTlmNS4u
OGMxOTlmOWZkZDUyMzk4NTI1NmZmMTlhNjAzNTllNTNkOGIyNTYxNiAxMDA2NDQKLS0tIGEvU291
cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAt
MSwzICsxLDE0IEBACisyMDE1LTA4LTA4ICBUaW5nLVdlaSBMYW4gIDxsYW50dzQ0QGdtYWlsLmNv
bT4KKworICAgICAgICBGaXggZGVidWcgYnVpbGQgd2hlbiBvcHRpbWl6YXRpb24gaXMgZW5hYmxl
ZAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTQ3ODE2
CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTm8gbmV3
IHRlc3RzIGJlY2F1c2UgdGhpcyBpcyBvbmx5IGEgYnVpbGQgZml4LgorCisgICAgICAgICogZWRp
dGluZy9JbnNlcnROb2RlQmVmb3JlQ29tbWFuZC5jcHA6CisKIDIwMTUtMDgtMDkgIEFuZHJlYXMg
S2xpbmcgIDxha2xpbmdAYXBwbGUuY29tPgogCiAgICAgICAgIFJlZi1pZnkgc29tZSBmdW5jdGlv
bnMgdGhhdCBhbHdheXMgc3VjY2VlZCBpbiBjb25zdHJ1Y3RpbmcgRG9jdW1lbnRzLgpkaWZmIC0t
Z2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2xsaW50L0xMSW50RW50cnlwb2ludC5jcHAgYi9T
b3VyY2UvSmF2YVNjcmlwdENvcmUvbGxpbnQvTExJbnRFbnRyeXBvaW50LmNwcAppbmRleCBiY2Qx
NGQ1YzlkYWQ4MzEzMDkzYmRhYTQ0ZmVlZWNhYTdmMzZmZTUzLi45ZDAwMTA2YjlhODI3NmY0ODQy
MGY2YjU0NmMzMmQ1OTMwYTM2YjY4IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUv
bGxpbnQvTExJbnRFbnRyeXBvaW50LmNwcAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvbGxp
bnQvTExJbnRFbnRyeXBvaW50LmNwcApAQCAtMjgsNiArMjgsNyBAQAogI2luY2x1ZGUgIkNvZGVC
bG9jay5oIgogI2luY2x1ZGUgIkhlYXBJbmxpbmVzLmgiCiAjaW5jbHVkZSAiSklUQ29kZS5oIgor
I2luY2x1ZGUgIkpTQ2VsbElubGluZXMuaCIKICNpbmNsdWRlICJKU09iamVjdC5oIgogI2luY2x1
ZGUgIkxMSW50VGh1bmtzLmgiCiAjaW5jbHVkZSAiTG93TGV2ZWxJbnRlcnByZXRlci5oIgpkaWZm
IC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL3J1bnRpbWUvRnVuY3Rpb25FeGVjdXRhYmxl
RHVtcC5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9GdW5jdGlvbkV4ZWN1dGFi
bGVEdW1wLmNwcAppbmRleCA2YzZkYmE3NmUxMzAzZjQyNjAxZWY3ZGNmZGJmZTcwNzg0MGM4MTVj
Li5kODBhOGU3MDFlYWM5MmEzN2Y0MDBkNzI2ZWI3YmNhOWMwOTNjYTZmIDEwMDY0NAotLS0gYS9T
b3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9GdW5jdGlvbkV4ZWN1dGFibGVEdW1wLmNwcAor
KysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9GdW5jdGlvbkV4ZWN1dGFibGVEdW1w
LmNwcApAQCAtMjUsNiArMjUsNyBAQAogCiAjaW5jbHVkZSAiY29uZmlnLmgiCiAjaW5jbHVkZSAi
RnVuY3Rpb25FeGVjdXRhYmxlRHVtcC5oIgorI2luY2x1ZGUgIkpTQ2VsbElubGluZXMuaCIKIAog
I2luY2x1ZGUgIkNvZGVCbG9jay5oIgogCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9lZGl0
aW5nL0luc2VydE5vZGVCZWZvcmVDb21tYW5kLmNwcCBiL1NvdXJjZS9XZWJDb3JlL2VkaXRpbmcv
SW5zZXJ0Tm9kZUJlZm9yZUNvbW1hbmQuY3BwCmluZGV4IDA5ZjliMWJiMzRjOTJlMzk0OTU5ZWE5
OTQzNTIwOTc0NTY2ZTNlNDQuLmZhMTRkMDc2NmVhZjc1ZmE0MzE5ZTZkODg1NzRhZjNkM2EwM2U0
MzYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2VkaXRpbmcvSW5zZXJ0Tm9kZUJlZm9yZUNv
bW1hbmQuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2VkaXRpbmcvSW5zZXJ0Tm9kZUJlZm9yZUNv
bW1hbmQuY3BwCkBAIC0yOCw2ICsyOCw3IEBACiAKICNpbmNsdWRlICJEb2N1bWVudC5oIgogI2lu
Y2x1ZGUgIkV4Y2VwdGlvbkNvZGVQbGFjZWhvbGRlci5oIgorI2luY2x1ZGUgIlJlbmRlckVsZW1l
bnQuaCIKICNpbmNsdWRlICJUZXh0LmgiCiAjaW5jbHVkZSAiaHRtbGVkaXRpbmcuaCIKIAo=
</data>

          </attachment>
      

    </bug>

</bugzilla>