When creating a Windows DLL one can easily choose exported symbols (using dllexport). In such situation symbols not exported are not visible outside the library. How can one get the same functionality on Linux?
In other words:
Let's say I have 10 functions in a project. Three of them should be exported, and the remaining 7 are helper functions that should not be usable from library API. How do i create SO file in such way, that lets me achive that?
On Linux/GCC by default everything is exported (depending on language rules, of course: something in an anonymous namespace will never be exported).
If you want to stop a symbol from being exported, you can use __attribute__((__visibility__("hidden"))). For example:
__attribute__((__visibility__("hidden"))) void myPrivateFunction();
Related
I am working with dynamic linked libraries (.dll) on windows or shared objects (.so) on Linux.
My goal is to write some code, that can - give the absolute path of the library on the disk - return a list of all exported functions (the export table) of that library and ultimately be able to call those functions. This should work on windows (wit dll) as well as on Linux (with so).
I am writing kind of a wrapper that delgates function calls to the respective library. Therefore I receive a path, a function name, and a list of parameters which I then want to forward. the thing is: I want to know whether the given function exists before trying to call it
From here I found a platform-independent way of opening and closing the library as well as getting a pointer to the function with the given name.
So the thing that remains is getting the names of available functions in the first place.
On this topic, I found this question dealing with the same kind of problem only that it asks for a Linux specific solution. In the given answer it is said
There is no libc function to do that. However, you can write one yourself (or copy/paste the code from a tool like readelf).
This clearly indicates that there are tools to do what I am looking for. The only question is, is there one that can work on windows as well as on Linux? If not how would I go about this on my own?
Here is a C# implementation (actually this is the code I want to port to C++) doing what I want (though windows only). To me, this appears as if the library structure is handled manually. If this is the way to go then where can I find the necessary information on the library structure?
So, on unixoids (and both Linux and WinNT have a posix subsytem), the dlopen function can be used to load a dynamic library and get function pointers to known symbols by name of that symbol.
Getting a list of symbols as far as I know was never an aspect that POSIX bothered to specify, so long story short, the functions that can do that for you on Linux are specific to the libc used there (GNU libc, mostly), and on Windows to the libc used there. Portable code means having to different codebases for two different libcs!
If you don't want to depend on your libc, you'd have to have a binary object parser (for ELF shared libraries on Linux, PE on Windows) to read out symbol names from the files. There's actually plenty of those – obviously, WINE has one for PE that is portable (especially works on Linux as well), and every linker (including glibc's runtime linker) under Linux can parse ELF files.
Personally, radare2 is a fine reverse-engineering framework with plenty of language bindings that is actually meant to analyze binary files, and give you exported symbols (as well as being capable of extracting non-exported functions, constructing call-graphs etc). It does have debugger, i.e. jumping-into-functions capabilities, too.
So, knowing now that
I am writing kind of a wrapper that delgates function calls to the respective library. Therefore I receive a path, a function name, and a list of parameters which I then want to forward. the thing is: I want to know whether the given function exists before trying to call it
things become way easier: you don't actually need to get the list of exports. It's easier and just as fast to simply try.
So, on any POSIX system (and that includes both Windows' POSIX subsystem and Linux), dlopen will open the library and load the symbol table, and dlsym will look up a symbol from that table. If that symbol is not in the table, it simply returns NULL. So, you already have all the tables you think you need; just not explicitly, but queryable.
Say I have a bunch of functions exported in a C++ DLL.
A customer asks for some code implementation which uses only some of the functions in the DLL.
I'd like to give the customer a DLL with the relevant functions only (because full DLL is too big, I dont want to send code he doesnt need to see, etc..).
Is there any way to export only part of the functions easily (e.g. without adding/removing "__declspec dllexport" declarations everytime)?
Perhaps "hide" function from full DLL or re-compile slimmer DLL (but control which functions included in a clean way).
Thanks!
I have a set of APIs that are explicitly designed to be used only in C++. I do not expect them to be used by a C program (or any other language for that matter), and as such I export namespace and class information as opposed to going the extern "C" route and using inlined utility functions to call the plain C functions.
Right now I am only working on dlls that are linked at compile time, which means importing the functions to the executable is very easy as it involves no work on my part. However, I plan on developing a plugin system which will require me to load dlls dynamically at run time. Will I be able to find name-mangled C++ functions using GetProcAddress()?
What you're doing is not necessarily a good idea unless you control the entire build chain and can ensure both your DLL and any apps using it are built with the same version of the same compiler.
With that said, yes, you can load name-mangled functions using GetProcAddress. Just use Dependency Walker or look at the generated .def file for your DLL, if your compiler is set to produce one, to get the mangled function name. Then you can GetProcAddress it. You cannot, however, call GetProcAddress with an unmangled name and expect it to find the right mangled name. For example, if your DLL's function is named Add, and is mangled to _Z3Addv, you would need to call GetProcAddress(myDLL, "_Z3Addv"); to access the function properly.
You would need to change the call to GetProcAddress every time you change the declaration of your function, since the mangled name would also change. Be aware you will also need to change the GetProcAddress call if you change the compiler your DLL is built with - MSVC's mangling is a lot different from GCC's, and clang's mangling is probably different from both of them. So you might want to reconsider the way you're doing this, since it seems rather prone to breaking somewhere along the way.
currently I am writing on a cpp-DLL. Afaik I have to put the functions into a class and a namespace if another cpp-program wants to use them. But I want to use the DLL with Labview too. Labview only recognizes the functions if they are free, e.g. neither in a namespace nor in a class. How can I implement this in my DLL? At the moment, I have set a #define-variable. If this variable is set, the functions are enclosed in a namespace and a class, if not, then they are free, but I have to compile the whole thing twice and I get two separate DLL files. So, what can I do if I only want one DLL file for both applications? (Please don't tell me to write the functions twice, the administrative outlay is even worse, I have tried this before).
Or do I simply have to call the DLL via LoadLibrary() when not using namespaces?
Thank you very much!
Afaik I have to put the functions into a class and a namespace if another cpp-program wants to use them.
This is plain wrong. You do not need to do this at all. On the contrary, DLL were originally introduced as libraries of C functions. C++ uses mangled names to represent namespace/class and types of parameters. There is no standard on this. Different compilers use their own scheme.
To summarize:
If you export simple C function from your dll, this will always work.
If you export classes or something from a namespace, this will
definitely work if other .exe/.dll is compiled with the same version of the
compiler. If not - this depends.
Regarding the LoadLibrary: it should be used when you do not know the name of the DLL or a name of the function in this DLL ahead or when you do not want to load this DLL at the beginning of your process. Otherwise (simple case) link your executable with implib for that DLL. This perfectly works for simple c-functions. LoadLibrary should be used when direct linking is not good for some reason.
I am a beginner, so, please bear with me, if this sounds too trivial.When i searched over the net for this, i got results showing how to do it. My question is why we do it in the first place ?
This is specific to the Windows platform, when you're developping C++ DLLs.
You have to use the __declspec(dllexport) modifier in order for your class and its methods to appear on the exported symbol list for your DLL.
This way, executables using your DLL can instanciate and call methods in these classes.
However you have to make sure that the executable and the DLL are compiled by the same version of the same compiler, because C++ symbols are exported using a relatively complex name mangling encoding (you can see that using depends.exe), which format varies from one compiler to another.
You don't need to export anything, unless you're creating a DLL. In that case, you can use the dllexport attribute as an alternative to the "old school" way of using .def files.
Technically you cannot export a class, only functions.
However you can designate on a class level that all functions be exported.
Exporting a function means that that function can be called from outside of the current executable.
This is needed when you are writing a dll for example which is a separate entity.