On Wed, Jul 29, 2009 at 10:46 AM, Evan Martin<e...@chromium.org> wrote:
>
> On Tue, Jul 28, 2009 at 11:18 PM, Brian Ryner<bry...@google.com> wrote:
>>>> > The -fvisibility=hidden flag is maybe supposed to do this (see
>>>> > discussion on http://gcc.gnu.org/wiki/Visibility ), but I tried
>>>> > building both with and without it and found that:
>>>> >  - in debug builds, objdump -T shows all of our symbols, regardless of
>>>> > the flags I pass to gcc or strip
>>
>> Can you paste a snippet of the objdump -T output you see for a debug binary?
>>  I'd also be interested in the answer to Mark's question -- is the binary
>> being linked with -E?
>
> As I said before, I don't really know what I'm doing -- I wrote my
> mail to mostly summarize the result of "tried building it both with
> and without this flag and saw no difference".
>
> There is no -E.   Maybe I don't understand what objdump -CT is telling
> me... aha!
>
> It turns out that the vast majority of the symbols I mentioned are C++
> templates.
> % objdump -CT out/Debug/chrome | wc -l
> 43740
> % objdump -CT out/Debug/chrome | egrep -v 'std|cxx' | wc -l
> 2591
>
> Here are a few examples of the output pre-filtering:
>
> 083fa306  w   DF .text  00000011  Base
> std::reverse_iterator<std::_List_iterator<std::pair<RenderWidgetHost*,
> BackingStore*> > >::base() const
> 090104dc  w   DF .text  00000022  Base        void
> std::swap<WebCore::CSSFontFace*>(WebCore::CSSFontFace*&,
> WebCore::CSSFontFace*&)
> 0
>
> Of the remaining symbols after that egrep -v, it's mostly stuff I'd
> expect, though I still see v8 templates marked weak:
>
> 091b7d12  w   DF .text  00000013  Base        v8::Local<v8::Integer>::Local()
> 00000000      DF *UND*  00000000  Base        gtk_tree_model_get_value
> 0884d056  w   DF .text  0000001a  Base
> v8::Local<v8::String>::Local<v8::String>(v8::String*)
> 00000000      DF *UND*  00000000  Base        gtk_grab_add
> 00000000      DF *UND*  00000000  Base        gtk_hbutton_box_new
> 00000000      DF *UND*  00000000  NSS_3.4     SSL_GetChannelInfo
> 00000000      DF *UND*  00000000  GLIBC_2.4   __stack_chk_fail
> 086a6698 g    DF .text  0000010a  Base        uprv_ebcdicFromAscii_3_8
> 0866af2e g    DF .text  000000d1  Base        uprv_fmin_3_8
> 00000000      DF *UND*  00000000  Base        gtk_widget_get_visual
> 091ab20c g    DF .text  0000005d  Base
> v8::ObjectTemplate::InternalFieldCount()
> 0885e164  w   DF .text  00000013  Base
> v8::Persistent<v8::String>::Persistent()
> 00000000      DF *UND*  00000000  Base
> gtk_file_chooser_set_preview_widget_active
> 00000000      DF *UND*  00000000  Base        gdk_display_get_pointer
> 0880e3a2 g    DF .text  000002f4  Base        ucol_tok_getNextArgument_3_8
> 086e6d5c g    DF .text  000001a1  Base        upname_swap_3_8
>
>
> Flags we use follow:
>
>        # Enable -Werror by default, but put it in a variable so it can
>        # be disabled in ~/.gyp/include.gypi on the valgrind builders.
>        'variables': {
>          'werror%': '-Werror',
>        },
>        'cflags': [
>           '<(werror)',  # See note above about the werror variable.
>           '-pthread',
>           '-fno-exceptions',
>           '-Wall',
>        ],
>        'cflags_cc': [
>          '-fno-threadsafe-statics',
>        ],
>        'ldflags': [
>          '-pthread',
>        ],

I have been going through the same pains with o3d, trying to get rid
of all exports, see http://codereview.chromium.org/160317 though I
haven't removed all of them.
It turns out that both ICU (all your u.*3_8) and v8 (that we both use
in o3d) force __attribute__((visibility("default"))) on some API
symbols (ie force export regardless of -fvisibility). You can get rid
of most of the ICU ones if you compile with U_STATIC_IMPLEMENTATION
but not U_COMBINED_IMPLEMENTATION, but there are still some left. For
v8, all the "public" API is tagged with "default" visibility.
For the STL template instantiations, I'm seeing those too, and I don't
know how to get rid of them.

Antoine

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to