disable more stacktrace usage in debug uclibc builds

disable more stacktrace usage in debug uclibc builds

Here are a couple more instances of OutputToStream / Print that are
no longer available in uClibc builds.

BUG=361130
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=264887

[Mostyn Bramley-Moore, 2014-04-11 08:45:04]

@Mark: I spotted a few more uses of OutputToStream/Print that need to be
disabled on uClibc, PTAL.

[Mark Mentovai, 2014-04-16 13:11:25]

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h
File base/debug/leak_tracker.h (right):

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h#ne...
base/debug/leak_tracker.h:9: #if !defined(NDEBUG) && !defined(__UCLIBC__)
Nothing says __UCLIBC__ will be defined here in a µClibc build. You haven’t
#included anything that would cause it to be defined.

[Mostyn Bramley-Moore, 2014-04-16 23:20:14]

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h
File base/debug/leak_tracker.h (right):

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h#ne...
base/debug/leak_tracker.h:9: #if !defined(NDEBUG) && !defined(__UCLIBC__)
On 2014/04/16 13:11:25, Mark Mentovai wrote:
> Nothing says __UCLIBC__ will be defined here in a µClibc build. You haven’t
> #included anything that would cause it to be defined.

Ahh, right.  

In my local branch I have some additional headers injected via the command line
(not something you would want me to submit) which include some other system
headers that in turn include features.h.

This file probably should include build/build_config.h, which should make sure
that this macro is set on uclibc builds.  However, it looks like that file needs
to add something like the following to build/build_config.h:

#ifdef OS_POSIX
// Make sure we have __GLIBC__ and/or __UCLIBC__ macros if we're building with
either of these C libraries
#include <features.h>
#endif

(Though perhaps OS_LINUX would be better?)

[Mark Mentovai, 2014-04-17 22:24:40]

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h
File base/debug/leak_tracker.h (right):

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h#ne...
base/debug/leak_tracker.h:9: #if !defined(NDEBUG) && !defined(__UCLIBC__)
Mostyn Bramley-Moore wrote:
> On 2014/04/16 13:11:25, Mark Mentovai wrote:
> > Nothing says __UCLIBC__ will be defined here in a µClibc build. You haven’t
> > #included anything that would cause it to be defined.
> 
> Ahh, right.  
> 
> In my local branch I have some additional headers injected via the command
line
> (not something you would want me to submit) which include some other system
> headers that in turn include features.h.
> 
> This file probably should include build/build_config.h, which should make sure
> that this macro is set on uclibc builds.  However, it looks like that file
needs
> to add something like the following to build/build_config.h:
> 
> #ifdef OS_POSIX
> // Make sure we have __GLIBC__ and/or __UCLIBC__ macros if we're building with
> either of these C libraries
> #include <features.h>
> #endif
> 
> (Though perhaps OS_LINUX would be better?)

<features.h> isn’t a standard header, so use OS_LINUX instead of OS_POSIX. I
don’t know if there are any Linux C libraries we care about that don’t have
<features.h>, but I do know that there are POSIXes that we care about that don’t
have this header. Mac OS X is the prime example.

Or, you could just include some other standard header that you know will cause
<features.h> and thus __UCLIBC__ to be defined if µClibc is the standard library
in use. I checked when you used __UCLIBC__ in other files, and there were
standard headers present that would have caused <features.h> to be included and
thus __UCLIBC__ to be defined.

[Mostyn Bramley-Moore, 2014-04-17 22:35:27]

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h
File base/debug/leak_tracker.h (right):

https://codereview.chromium.org/234803002/diff/1/base/debug/leak_tracker.h#ne...
base/debug/leak_tracker.h:9: #if !defined(NDEBUG) && !defined(__UCLIBC__)
> Or, you could just include some other standard header that you know will cause
> <features.h> and thus __UCLIBC__ to be defined if µClibc is the standard
library
> in use. I checked when you used __UCLIBC__ in other files, and there were
> standard headers present that would have caused <features.h> to be included
and
> thus __UCLIBC__ to be defined.

I though about this a bit, but wasn't sure which system header would be most
suitable to include.  How about unistd.h?

[Mark Mentovai, 2014-04-18 19:18:50]

LGTM, I guess. There’s no elegant way to handle this. The other alternative
would have been to not mess with build_config.h at all, and just #include
<unistd.h> at the top of leak_tracker.h. I might like that better just because
it’s a little bit less polluting: pretty much the world #includes
build_config.h, but not everyone needs or wants <unistd.h> (and those that do
need or want it should #include it themselves).

But that’s also quirky, and I don’t dislike doing this in build_config.h enough
to ask you to change it to that.

[Mostyn Bramley-Moore, 2014-04-18 21:04:50]

On 2014/04/18 19:18:50, Mark Mentovai wrote:
> LGTM, I guess. There’s no elegant way to handle this. The other alternative
> would have been to not mess with build_config.h at all, and just #include
> <unistd.h> at the top of leak_tracker.h. I might like that better just because
> it’s a little bit less polluting: pretty much the world #includes
> build_config.h, but not everyone needs or wants <unistd.h> (and those that do
> need or want it should #include it themselves).
> 
> But that’s also quirky, and I don’t dislike doing this in build_config.h
enough
> to ask you to change it to that.

I agree on all points (except I really dislike the idea of relying on client
code to include a system header before build_config.h).  

Before I check the CQ box, I'll brainstorm a few alternatives:
1. Just #include <features.h> inside the OS_LINUX block (breaking linux
non-{glibc,uclibc}).  
2. Add a 'linux_libc%': 'glibc' setting in build/common.gypi and allow builders
to specify linux_libc=uclibc.  
3. Add a 'linux_glibc%': 1 setting, and treat all linux non-glibc setups as
second class citizens (which is not that far from the truth).  
4. Add a 'linux_features_h%': 1 setting and define NO_LINUX_FEATURES_H if it's
!= 1, then include features.h in the OS_LINUX block in build_config.h if this is
not defined.  
5. Try to hack together a gyp-time compile test.  
6. Add a gyp target that uses an action to generate a header (based on a compile
test) which build_config.h includes, and make the base target depend on it (on
linux).
7. Add a 'use_glibc_backtrace%': 1 gyp setting, and use that to create a
GLIBC_BACKTRACE (or NO_GLIBC_BACKTRACE) macro, and use that everywhere.

I think (4) is perhaps the least-inelegant solution, and (6) is perhaps the most
general (but also slightly over-complicated) solution.  But simply including
unistd.h in build_config.h is not that bad IMO.  

Do you prefer any of these alternatives to patchset 2?

[Mark Mentovai, 2014-04-18 21:15:22]

-1 to anything that involves GYP variables for this. Let’s just go with patch
set 2.

[Mostyn Bramley-Moore, 2014-04-18 21:17:19]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-04-18 21:18:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mostynb@opera.com/234803002/20001

[commit-bot: I haz the power, 2014-04-18 23:40:20]

Change committed as 264887