On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
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?
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.
This construct seems like it should be rejected by the C++ front-
end. The source is making two contradictory claims: the struct is
not visible outside this library, but part of it is implemented
outside of it. This should be rejected by the front-end, not the
linker IMO.
-Chris
