For a while, I've been using a small collection of files I wrote making it easier to interface with WinAPI. Although, it's become a pain to keep moving the files around when I want to reuse them, waiting for them to recompile, etc. I finally decided to just throw them in a DLL, and be done with it, but I'm getting an odd link error every time I try to use the library.
The error is really as specific as the title, providing little information about where the definition actually originates(considering, that kind of information can't really be collected from a DLL, as far as I'm aware). Could someone please explain exactly what would cause this error, as well as providing some possible fixes to the problem?
I'm using MinGW(the same version provided by the SFML site, 4.4) along with Code::Blocks, if that information helps any. If any more information is required, I'll do my best to provide it.
The problem is that there are multiple definitions for a symbol (function or variable) named _Unwind_Resume.
The DLL is exporting such a name. Rebuild it so that it only exposes desired symbols. Apparently, it is now built with all public symbols being exported.
Related
I'm trying to import C++ functions from an instrument SDK into LabVIEW, and I'm running into issues with function decorations. I have a header file, the dll, a lib, and a .exp file. Unfortunately, I only have the function declarations in the header. If I had the definitions, I'd recompile the dll using the "extern C" flag I've read about.
I feel like I should be able to wrap the SDK's dll in some way using a definitions file or something to translate the compiled function names and effectively "unmangle" them for LabVIEW. Something (very loosely) like:
myFunc(arg){
?myFunc#Class#namespace##otherstuff(arg);
}
However, I haven't been able to find any discussion about this anywhere I've looked. It's entirely possible that it's abstracted enough that I don't recognize it when I see it, but I feel like it's more likely there's a reason this isn't done.
So, that's my question: can [referencing one dll from another] be done, since I've never seen dll imports combined with exports, and could I do that to get around the need to recompile the dll from the original code?
I'm guessing no, but I'd love to be wrong.
I know this sounds like "can I have dynamic static linkage" which makes little sense, but let me explain.
I am looking for options to explore and I am aware that there might be something out there that I'm not aware of.
My goal is to have a modular code base where plugins would be provided as static libs, to avoid having exposed dll and result in a single library which clients could swallow in their code.
I imagine having a config file listing all the desired plugins, feed that to a script and boom : a magic sln file with everything ready to be built.
My initial idea is to have a 'main deck' that would know every possible plugin interface and link with them all. Plugins not yet implemented or required by the client would be dead-end/no-op implementations, while required plugins would be implementations realizing the interfaces called by the 'main deck'.
I think that would work, but I find conceptually horrible the idea of linking dead implementations for the sake of modularity.
The main issue I see is at that 'main deck' level : how could I remove useless headers to prevent useless linking or add newly developed ones without editing the code each time? I cannot figure this out without a ton of macros or generating some source files.
Could other patterns solve that issue?
I think there is no possible way that doesn't involve macro magic and a complex build system.
If I understand correctly, what you want to do is similar to a library I have used, rocksdb. At build time you can specify what modules/packages you want and it will build them into the static library for you. Check out what they do and see if it is along the lines of what you want.
I need to work with a .dll (c++ 64bit) which is made by one of my company's vendors, and they no longer exist. I don't have the header file (.h).
I follow this:
Get the function prototypes from an unknown .dll
I was able to get the function name, but I don't know what the function return type and parameters are.
I tried dependency walker too, same result.
This dll is not a public dll, it is customized for our company to use, so the functions inside cannot be searched online.
Are there any tools or methods that can help me retrieve this info?
I need to work with a .dll (c++ 64bit) which is made by one of my company's vendors, and they no longer exist. I don't have the header file (.h).
In a professional setting, that is a symptom to give up immediately using that library, and find and use something else. Yes, that costs money and time (so advise your manager and/or client). You might prefer using some free software library instead next time (because then you could at least continue maintaining that library, even if its vendor disappeared).
You could consider that C++ usually do name mangling and try to reverse-engineer something (but you won't be able to guess the fields inside class-es reliably or other information related to types). I don't recommend trying, since that could take a lot of time & money and you won't be able to guess everything (so you don't know if you'll guess enough information to use that stuff).
(what happens to you is a project mismanagement mistake, not a developer's mistake)
Using (even a few minutes) as a developer a C++ library without full headers and documentation for it is just crazy. Don't do that.
So there is no technical solution to your issue. Decompilation is generally impossible (and costs a big lot and usually don't work well)
Dependency walker should work for you. Here is an overview of how the functions, return types and arguments are displayed:
[dependency walker overview] https://kb.froglogic.com/download/attachments/2457645/dependency_walker_provided_information.png?version=1&modificationDate=1341338967000
Remember that you have to use a different version of dependency walker for 32bit or 64bit dll.
What is more, if you see some strange symbols in your function parameters like #,# etc..., then you are missing some dependent dll.
There is plenty of information available about how to export functions from a dll (which I've done many times), but I heard that it's also possible to export functions from an executable, so that an external dll can call them.
Although I've managed to get this working, it seems as though there's some problem with the entry point:
If it is not explicitly set, then it defaults to the wrong "main" in
an obscure sub-library.
If it is explicitly set, then its input arguments, argc and argv get corrupted (argc can be ~20000000 or ~-700000).
I'm having trouble finding any documentation on exporting functions from an executable - should I be taking the hint and not doing it?
[Context: This was part of an effort to make our process work on both Windows and Linux. The Linux version was accidentally picking up functions from the executable, rather than ones explicitly exported from an attendant dll (the functions had the same name, but different args). We decided to try to run with this, and export the functions from the executable on Windows as well.]
I'm posting this just to summarise my own learning on this, in absence of a better answer:
Immediately after adding the def file, the linker complained that it couldn't determine an entry point. It was for this reason that I added the /ENTRY reference. During rework, however, I removed the /ENTRY while removing the def file, and I could compile without error - I must have removed a subtly conflicting option in the meantime.
The def file does export the functions from the .exe successfully, and these can then be used in a dll of that process (if it links to DelayImp.lib and the executable's .lib).
I was never able to get the /ENTRY option to work satisfactorily, and combined with the mildly discouraging comments on the MSDN item [https://msdn.microsoft.com/en-us/library/f9t8842e.aspx], I see no reason to use it in this case.
I hope that this is of some use to anybody else attempting to do something similar. I will be happy to re-designate a more technical answer as "the solution", should one appear...
Issue
I have recently found myself working with a large, unfamiliar, multi-department, C++ codebase in need of better organization. I would like to discover a way to map which symbols are used by which source files for any given header. This is in the hope that if only one department uses a given function, then it can be moved out of the shared area and into that department's area.
Attempts
My first thoughts were to use the symbol table: ie. compile the project and dump the symbols for each object file. From there I figured I could simply write a script to check if the symbols from my header file were used. While this approach seems viable, it would require me to create a list of symbols I am looking for from the headers. With my limited knowledge, I am unsure of how to automate such a process, and with hundreds of headers files to test, doing it manually is out of the question.
Questions
Is my approach valid? If so..
What can I use to generate the symbol names from my header file?
If not..
What else can I do?
Additionally, while I am using Linux, most of the development teams work in Windows only environments. What utilities could I use on both platforms?
Any and all help is greatly appreciated.
When I need to clean up APIs I sometimes use information from callcatcher. It basically builds a database of all symbols while compiling and allows you to determine what symbols are used in some build product.
I sometimes also use DXR (code on github, an example installation) to browse what code defined where is used how. In contrast to callcatcher with DXR you can drill down to much finer detail. Setting up DXR is pretty heavy duty, but might be worth it if you have enough code to work with.
On the other side of the spectrum there are tools like cscope. Even though it doesn't work super nicely with C++ code it is still very useful. If you deal with more than a couple 100kloc you will quickly feel limited though.
If I had to pick only one of these tools and would be working on a large code base (>1Mloc) I would definitely pick DXR.
You can get a reasonable start on the information that you've described by using doxygen.
Even for source that doesn't contain the doxygen formatted comments the documentation created can contain a list of places (ie. source files) where a particular symbol is used.
And, as doxygen can be used to generate html documentation, navigating through your source tree becomes trivial. It's can be even better if you enable the dot functionality to generate relationship diagrams for the classes in your source tree.
very old-school, simple, and possibly unix only, but are you aware of etags? there's also gnu global which i think is similar.
the gnu global link refers to the "comparison with similar tools" discussion here which might also be useful.