-Bsymbolic is good too, but I don't want the compiler to have to know if something is "local" or "external" (making up terminology there!)
In windows, you can just say:
void F1();
void F2() { F1(); }
and whether or not F1 is in the .so/.dll/.exe as F2, it doesn't matter.
The compiler doesn't have to know. It can generate the same simple sequence no matter what.
>> You don't need visibility or declspec or anything. <<
You *can* say:
__declspec(dllimport) void F1();
void F2() { F1(); }
but that is only a small optimization -- one instruction per call to F1.
And if you get it wrong, well, you'll pay that extra instruction and you'll get a linker warning.
If you don't say __declspec(dllimport) and F1 happens to be imported, the linker will generate a single instruction stub called just plain F1, that just does jmp DWORD PTR[__imp__F1].
Imho the best simplest thing is not to sprinkle all the annotations around.
Bind to everything "directly", and let the static linker fix it up.
One small problem in this scheme, which might be present in others anyway, is function pointer equality often doesn't work. But comparing function pointers for equality is pretty rare.
Heck, if you do say __declspec(dllimport), then I think you lose constantness of function pointers. You lose somehow either way, but not always by much. Dynamic linking just wasn't considered back in the day.
There is also a problem with importing data, but data imports are rare and imho to be avoided.
You know, in detail: __declspec(dllimport) foo tells the compiler, that there exists a pointer called __imp__foo that it should use instead of foo. Same thing for data or functions. But for data access, the linker can't so easily insert a stub. Though cygwin does cope with this somehow anyway.
__declspec(dllexport) just passes on the information to the linker -- same as listing the symbol in a .def file, but saving you from knowing the mangled name, and/or exporting classes en-masse instead of individual functions.
For C code, one can just maintain the .def file.
So no need for either dllimport or export.
Windows also always has what on Darwin they call "two level namespaces".
The imports are a two level hierarchy, dll name/function name.
That is a different point though. I can live with that either way.
There is no accomodating widescale "interposition".
Thanks,
- Jay
----------------------------------------
> To: jay.krell@xxxxxxxxxxx
> CC: gcc-help@xxxxxxxxxxx
> Subject: Re: ideal visibility setting?
> From: iant@xxxxxxxxxx
> Date: Tue, 18 May 2010 16:42:11 -0700
>
> Jay K writes:
>
>> In particular, will any of GNU ld, Sun ld, Apple ld generate stubs
>> for stuff that was marked hidden but turned out to come from an .so?
>
> I don't think so. A symbol that is marked hidden can't come from a
> .so, by definition. That sounds more like -Bsymbolic.
>
>> As well everything that is exported, I want "protected" (which
>> doesn't currently work in gcc), so telling the compiler "hidden"
>> might be close enough to true?
>
> As far as I know protected does work, though it doesn't mean what some
> people think it should mean. In what way does it not work for you?
>
> Ian
