Bill Wendling wrote: > On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote: > >> Consider: >> >> struct __attribute__((vsibility ("hidden"))) S { >> void __declspec(dllimport) f(); >> }; >> >> At present, we give "f" hidden visibility. That seems odd since the >> user has explicitly told us that the symbol is coming from another >> shared library. >> >> I'm planning to make any dllimport or dllexport attribute imply default >> visibility. Is that a bad idea? >> > Perhaps I'm mistaken, but the above seems to indicate to me that the > structure (and, therefore, all of its fields) are hidden, one of its > functions is from an external and visible source.
Yes. And, therefore, emitting a undefined reference to S::f with hidden linkage in the current translation unit causes S::f to have hidden visibility in the shared object containing this translation unit. For example, if the translation unit goes on to say: void g() { S s; s.f(); } we will now have an undefined reference to S::f with hidden visibility. As a result, S::f will have hidden visibility in the shared object containing this translation unit. Thus, despite dllimport, the user cannot actually import a function of a hidden class from another DLL. That seems bad. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713