From Rik Heywood on Mon, 15 May 2000
I am trying to create a shared library that my other programs can load and use. I have managed to get this to work and all is well. However, I am trying to limit the functions that the library exports to just the ones I want. On win32 there are numerous ways of achieving this (eg listing the functions you want to export in a .def file, adding __dllexport to the function definition). I feel sure it will be possible in Linux, but so far I have been unable to figure it out. Any ideas?
I don't know why you'd do such a thing. It can't possibly be used for any security purpose (either someone or some program has read/execute permission to the whole shared library, or not).
From what I gather you "export" a C function from a library by documenting its interface in a header (.h) file. Frankly even if the feature exists I think it would be of dubious value. If you limit access to some function you must make the programmer re-implement it in their space (goes against code re-use). If the do that then they've forked to functionality and any refinement of the function(s) must now be done in multiple places (bad for maintainability). If you are simply trying to discourage the use of some internal interfaces (since they may change and you don't want to be saddled with backward compatabilty responsibilities in those particular areas) then just comment and document them as internal (in your sources) and separate their prototypes into a different set of header files (which are not installed into the public include directory tree).
However, I'm not an expert. In fact I don't even consider myself to be a professional programmer (though I've done a bit of it here and there). So it's certainly possibly that everything I've just said is idiotic gibberish. (Of course that would be possible even if I was a recognized expert).
As for the fact that this "feature" exists in Microsoft DLLs and programming tools --- it sounds like it's probably primarily useful if you need to create binary products that take advantage of "hidden" (undocumented) private interfaces which you plan to keep from your competitors.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18