Bug 78735 - Several missing/incorrect guards for LOG_DISABLED=0 against Release build (Mac)
Summary: Several missing/incorrect guards for LOG_DISABLED=0 against Release build (Mac)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-15 13:28 PST by Brian Burg
Modified: 2013-11-22 09:41 PST (History)
10 users (show)

See Also:


Attachments
Failing build log in Mac when setting the GCC_PREPROCESSOR_DEFINITION "LOG_DISABLED" to 0 (61.40 KB, application/octet-stream)
2013-11-22 08:31 PST, Andres Gomez Garcia
no flags Details
Patch (1.36 KB, patch)
2013-11-22 08:33 PST, Andres Gomez Garcia
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Burg 2012-02-15 13:28:40 PST
Steps to reproduce:

1. Add #define LOG_DISABLED 0 near the top of wtf/Assertions.h (this is behavior that should be supported; see the top of Assertions.h)
2. Compile on Mac for Release build
3. Build will fail when linking WebKit2


Causes:

In WebKit2/Platform/mac/Logging.mac.mm:

* the implementation of WebKit::initializeLogChannel should be guarded by #if !LOG_DISABLED, but is actually guarded by #ifndef NDEBUG. This will cause build breakage if LOG_DISABLED is manually set to false in wtf/Assertions.h, but WebKit is compiled in release mode.

In WebCore/Exports/ExportFileGenerator.cpp and WebCore.exp.in:

* the export of symbol __ZN7WebCore20LogNotYetImplementedE is similarly improperly guarded by #if !defined(NDEBUG), whereas it should be guarded by #if !LOG_DISABLED


(I don't have a working copy, so can't produce a usable patch right now. But this is a 5 minute fix.)
Comment 1 Andres Gomez Garcia 2013-11-22 08:31:34 PST
Created attachment 217686 [details]
Failing build log in Mac when setting the GCC_PREPROCESSOR_DEFINITION "LOG_DISABLED" to 0

(In reply to comment #0)
> Steps to reproduce:
> 
> 1. Add #define LOG_DISABLED 0 near the top of wtf/Assertions.h (this is behavior that should be supported; see the top of Assertions.h)
...

This is not needed, it can be achieved with:
$ Tools/Scripts/build-webkit GCC_PREPROCESSOR_DEFINITIONS='${inherited} LOG_DISABLED=0'

...
> Causes:
> 
> In WebKit2/Platform/mac/Logging.mac.mm:
> 
> * the implementation of WebKit::initializeLogChannel should be guarded by #if !LOG_DISABLED, but is actually guarded by #ifndef NDEBUG. This will cause build breakage if LOG_DISABLED is manually set to false in wtf/Assertions.h, but WebKit is compiled in release mode.
> 
> In WebCore/Exports/ExportFileGenerator.cpp and WebCore.exp.in:
> 
> * the export of symbol __ZN7WebCore20LogNotYetImplementedE is similarly improperly guarded by #if !defined(NDEBUG), whereas it should be guarded by #if !LOG_DISABLED
...

This is not true anymore since this guards where changing some time ago.

However, compiling with LOG_DISABLED=0 is not workind due to missing dependencies as shown in the attached log file.
Comment 2 Andres Gomez Garcia 2013-11-22 08:33:40 PST
Created attachment 217687 [details]
Patch
Comment 3 Mario Sanchez Prada 2013-11-22 08:54:59 PST
Comment on attachment 217687 [details]
Patch

Looks ok to me
Comment 4 WebKit Commit Bot 2013-11-22 09:41:40 PST
Comment on attachment 217687 [details]
Patch

Clearing flags on attachment: 217687

Committed r159695: <http://trac.webkit.org/changeset/159695>
Comment 5 WebKit Commit Bot 2013-11-22 09:41:43 PST
All reviewed patches have been landed.  Closing bug.