I have a dynamic library A.dll which consumes a static library B.lib containing a function "int foo()". When I use dumpbin (on win32, vs2010) to view the symbols in dll - foo is not visible - Is that expected? or is it Microsoft specific? I tested this on linux and that is not the case on linux.
Thanks very much for your patience to read this through.
Kapil.
Yes, this is expected. As far as the imported symbols are concerned, using dumpbin, you can see the so called Import Address Table and the Import Name Table which both (typically) exist as soon as at least one function is imported by an application (in your case A.dll). Since your application imports one function from a STATIC library (in your case B.lib), NO entry exist in the imports tables mentioned above for the functions used from B.lib. Once a library is STATICALLY linked to an application, its body (code) is part of the application. As well as the functions of your application are not visible using dumpbin, the functions of the static library are not visible to dumpbin!
Related
Using Cmake I would like to know how to create a wrapper library and let the users link their application with this library only. Users don't need to specify the original library in their linker flags.
For instance, I create a wrapper library for libwebsockets, named libcustomws.
add_library(customws main.c)
target_link_libraries(customws websockets)
I would like user (with no libwebsockets installed) to be able to do:
add_executable(user_app user_app.c)
target_link_libraries(user_app customws pthread)
Wrapper libraries without any additional code from within your project can best be implemented with small INTERFACE library targets with the IMPORTED tag. Example for your scenario:
add_library(customws INTERFACE IMPORTED)
target_include_directories(customws
INTERFACE
/some/include/path)
target_link_libraries(customws
INTERFACE
websockets)
This way, targets that use this library can just
add_executable(user_app user_app.c)
target_link_libraries(user_app customws pthread)
and get the usage requirements from the target customws, in this case an include directory and a linked library (websockets) are propagated through customws. This can be a good thing, as it might encapsulate implementation details of the dependency (different flags for different platforms etc.).
If you like to automatically link to compiled code (that is part of your project), this can be easily done by adding a small intermediate OBJECT library, e.g.
add_libraray(customwsenhanced
OBJECT
someCode.c)
target_link_library(customwsenhanced
PUBLIC
customws)
Depending on whether someCode.c depends on the usage requirements of customws, the target_link_library for customwsenhanced could also use INTERFACE propagation. Now, a client application can go with
add_executable(user_app user_app.c)
target_link_libraries(user_app customwsenhanced pthread)
and will get both the compiled object code of someCode.c as well as flags etc. from customws.
Good day,
I have used dll imports for "user32.dll" in the past.
However, I am trying to import a class library into my application which has some namespaces which come into conflict with namespaces which are already imported and referenced from other class libraries.
How can I reference this dll and only use the namespaces contained in it, or override the other namespaces imported from other class libraries in one class without it affecting the rest of the application.
I am still pretty new, this may not be possible.
Thank you.
To summarize the relevant issues:
In VB.NET one can use the Declare statement to call win32 functions in DLL's with typical EntryPoint constructs.
.NET Assemblies do not provide classical Win32 type EntryPoints (as such they cannot be 'declared')
If one needs to reference a .NET Assembly [or COM] you need to add a reference to the target library when compiling (usually done in the VS IDE or with the /r: switch)
In some cases Namespaces of such referenced Assemblies may collide with others. (i.E. referencing the same Assembly in different versions)
In that case one needs to import the required (conflicting) Namespaces with an Alias
For example:
Assuming you have an assembly with a root namespace Net that could collide with System.Net use:
Imports System
Imports ExtNet = SomeNetworkAssembly
Then in this case to access members of that assembly use ExtNet instead of Net
Note you can name the ExtNet part as you wish.
In C# one can do it via the using keyword instead.
I am studying the Revised7 Report on the Algorithmic Language Scheme. My question is on section 5.6 Libraries.
In this section, it says:
When a library is loaded, its expressions are executed in textual order. If a library's definitions are referenced in the expanded form of a program or library body, then that library must be loaded before the expanded program or library body is evaluated. This rule applies transitively. If a library is imported by more than one program or library, it may possibly be loaded additional times.
What is this supposed to mean? Does it mean that a library is loaded only if an imported identifier is actually being referenced or already when the library is part of an import set of an expanded program or library? If the same library is being referenced by two other library imported by the same program, is the library loaded twice or just once?
As the loading of a library may have side-effects due to the execution of its expressions, the answers to these questions seem important to me. Also, do share the two libraries that import a third library its internal global variables?
I have done some experiments with chibi-scheme: Per program, chibi-scheme loads every library only once and even if none of its exported identifiers are actually referenced. In fact, this looks like a sensible and easily implementable thing to me.
P.S.: There is another point where I think the specification is a bit vague: What happens if, in a program, an import set imports an identifier named import? Does it mean that an immediately following line (import ...) is interpretated as a command or definition (depending on what the imported identifier import stands for) or still as an import set?
P.P.S.: What is even the reason for allowing more than one import declaration in a top-level program?
Let me attempt to answer each of your questions one-at-a-time. Also, if it would help, here is a link to the meta-language used to implement libraries in chibi scheme.
A library is loaded when it is imported via an import statement.
If a library's definitions are referenced in the expanded form of a program or library body, then that library must be loaded before the expanded program or library body is evaluated.
This just means that the library must be loaded before its definitions are referenced (or it would be an error, since the definitions would not be found).
If a library is imported by more than one program or library, it may possibly be loaded additional times.
This is implementation-dependent, so your library code should not make assumptions that it will only be loaded once.
What happens if, in a program, an import set imports an identifier named import?
Most likely, the new import identifier would shadow or replace the import, so that any import statements in the same scope would no longer work as expected. This might be implementation-dependent - if import is implemented as a special form then it would not be overridden by a newly introduced identifier.
i have a compiled dll library but i have no documentation about it. There is a way to get the public interface of a dll (at least function names, params numbers and type).
Thanks
You would have to decompile it and analyze each function, its calling convention, parametrs count, parameters meaning (unless it comes with some PDB, but I doubt it), I've done something like this before, it's complicated work, but it can be done.
In order to retrieve the public symbols (functions and variables) exported by a Dynamic-Link Library, one can use the well-known dependency walker. Parameters and Types are only available when the associated PDB file is available (which does not seems to be your case).
You could use the OLEViewer that comes with Visual Studio to view the TypeLib of the DLL if it is a COM library. This would give you the information you need.
It can be used to run arbitary Dynamic Link Library in windows,
how can it possibly know the entry point of an arbitary dll?
The answer depends on how much details you need. Basically, it comes down to this:
A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL.
[...] If you are providing your own entry-point, see the DllMain function. The name DllMain is a placeholder for a user-defined function. You must specify the actual name you use when you build your DLL.
(Taken from the MSDN article Dynamic-Link Library Entry-Point Function.)
So basically, the entry point can be specified inside the DLL, and the operating system's DLL loader knows how to look this up.
The IMAGE_OPTIONAL_HEADER (part of the portable executable's header on Windows machines) contains an RVA of the AddressOfEntryPoint that is called by programs looking for an entry point to call (e.g., the loader).
More information on the IMAGE_OPTIONAL_HEADER can be found here. And this paper is good for just general PE knowledge.
What do you mean by "run a DLL"? DLLs aren't normal programs, they are just a collection of functions. The entry point itself usually doesn't do much apart from initializing stuff required by other functions in the DLL. The entry point is automatically called when the DLL is loaded (you can use LoadLibrary to do this).
If you want to call a specific function after loading the DLL, you can use GetProcAddress to get a pointer to the function you want.