gperftools should not export all of its symbols

[GoogleCodeExporter]

Currently, gperftools exports all of its symbols in the libraries that it 
produces. This can cause conflicts with other code which uses google libraries. 
For example:

$ nm thirdparty/installed/lib/libtcmalloc.so | grep CyclesPerSecond
00000000000351a0 T _Z15CyclesPerSecondv
0000000000034c60 t _ZL23EstimateCyclesPerSecondi
00000000000400e0 r _ZZL23EstimateCyclesPerSecondiE19__PRETTY_FUNCTION__

will cause linkage errors if other Google-derived source tries to use tcmalloc.

To fix, the build should probably pass -fvisibility=hidden and then use 
__attribute__((visibility("default"))) for the public-facing APIs (eg 
MallocExtension, HeapChecker, etc)

See http://gcc.gnu.org/wiki/Visibility for more info.

Original issue reported on code.google.com by tlip...@gmail.com on 5 Jan 2014 at 2:25

[GoogleCodeExporter]

Yes. A patch for that would be very nice to have.

Original comment by alkondratenko on 5 Jan 2014 at 2:29

[GoogleCodeExporter]

Upon further investigation it looks like _some_ of the libraries use 
--export-symbols-regex in their LDFLAGS to try to contain this. But not 
libtcmalloc itself. I think the source-code (attribute) based approach is 
easier to reason about, but wondering if there is a portability concern.

It looks like once upon a time the libtcmalloc symbols were hidden, but it got 
changed in c437e1fcdd1e6ff3f032928d460cbfc115e2324f 
(http://gperftools.googlecode.com/svn/trunk@36). csilvers, you out there to 
comment?

Original comment by tlip...@gmail.com on 5 Jan 2014 at 3:13

[GoogleCodeExporter]

visibility itself is simple to do (because we already handle dll_export for 
windows). I believe hardest thing is that lots of tests are using "internal" 
symbols. Which would be unavailable with -visibility=hidden

Original comment by alkondratenko on 5 Jan 2014 at 3:43