> On Thu, Aug 29, 2013 at 02:47:46PM +0200, Paolo Carlini wrote: > > On 08/29/2013 02:19 PM, Jan Hubicka wrote: > > >So my belief is that it is safe to drop those symbols from > > >libstdc++. Every program/DSO using them have to define its own > > >copy of those symbols, so I believe removing them from libstdc++ > > >won't cause issues. > > Really, you should check with Jakub before proceeding. I the change > > it's Ok with him, it's Ok with me too (the other library maintainers > > should be in CC however). At minimum the baselines would need > > updating. > > I'm very nervous about removing any exported symbols, apps could dlsym them > or whatever. So, if the compiler makes those hidden, either there should be > an option to restore the old behavior and libstdc++ should use it, or we > need some renaming/alias hacks to restore those.
I can add an option to disable it ( would -fno-private-inlines work?) that will disable this transformation to hidden as well as LTO comdat localization when symbol is PREVAIL_EXT? Of course if we are affraid to remove the symbols from libstdc++, I wonder how safe we are about APIs of other C++ libraries. Do you think people dlsym inline functions and comdat vtables from dlopened DSOs? Honza > > Jakub