I guess this is a simple question since I don't have much information about creating dll's
I wanted to use the deprecated Qt PieMenu in a project, I found the source code here.
After I did the necessary changes to the source code, I needed to build a dll from the source file (because it's licensed under LGPL).
The INSTALL.TXT file explains the steps.However, I'm always getting a .lib file instead of the dll.
I have no idea what I'm missing because I'm following the instructions without much understanding the whole idea.
Any help is appreciated.
Related
I am new to Unreal Engine. But here is what I planned to do. I want to an experiment project by combining socket.io with Unreal Engine 4. I know somebody may shot at me, for it already had a plugin. But I don't like graph programming at all (I prefer "real" coding)
But as I followed instruction from Installing socket.io C++ and here. It just won't work. The error told me something about File Not Found on multiple headers file from this github repo. So I tried to add a lot of things (Hopefully it won't affect the outcome). And now a tons of errors had popped up. Now they are mostly about Macro errors. And I have absolutely no idea how to fix.
The problem is I don't understand why after I include .lib files to PublicAdditionalLibraries I still needed the original file (Shouldn't it work like any other visual studio projects?)
Also how to tackle loads of errors I am facing
Thanking in advanced
Did you add your include paths with the lib headers to PublicIncludePaths array ( in the StartupModule() method ? it's gonna be needed to use methods from your lib.
Here is an exemple how to use the PublicIncludePaths
string includePath = Path.Combine(ThirdPartyPath, "opencv", "include");
PublicIncludePaths.Add(includePath);
ThirdPartyPath is a member of my module class i retrieve with my getter
Path.GetFullPath(Path.Combine(ModulePath, "../../ThirdParty/"));
I took a look at the github repo of Socket-IO-cpp lib and the only libs compiled for windows are in 32bits, take care you're not tried to compile in 64bits, or every .lib files of your libraries are in 32bits to be linked all together, in case you're using others libs.
If you got some runtime error, take a look at my answer which explain how to indicate .dll when .libs arn't enough.
Hope it helps
I have no prior experience with .dll or .lib files and I need to see the code of a function in these files. I don't know which one to look at, searching around in stackoverflow led me to dumpbin, and I can use dumpbin /EXPORTS to see the headers and the functions are there. But how can I see the actual code? Can I do it just via the console or do I have to download a separate program?
P.S: I use Visual Studio and these are C++ functions.
Any help would be appreciated.
Seeing the source code from a compiled file such as a .lib or .dll is nearly impossible since it is basically a compiled file.
By compilated the source code you will lose some information as comments and most code structure. So your library file don't have those informations anymore. However a few options are still possible.
Obvious first, if your library come from an open-source project you may find the source code by asking our dearest friend.
Depending of what you really want to do with this library, tools such as dumpbin, objdump or else can give you more information on your existing file by reading and decoding some part of the file (headers, table name).
Eventually, you can try to transform your binary into something more readable like assembly or pseudo source code using something like a disassembler or a decompiler although its result will not be the original code source.
I'm currently writing a native extension for NodeJS. This is basically a dll that NodeJS will load when you ask for it.
I have VS2012 attached to the Node process. I want to debug into Node's code that does the loading.
I have the .cc and .h files for node, but there are no .pdb files that I can find. How can I set a breakpoint in the Node source?
UPDATE: I DO have a node.lib file. Can that be a replacement for a pdb?
UPDATE 2: Tangential, but for anyone specifically debugging NodeJS, Node actually DOES ship a pdb, available at http://nodejs.org/dist/v0.8.22/node.pdb (replace the version number with whatever version you're looking for).
Without a way to relate actual source code to assembly code, you cannot debug from source code. You need a pdb file.
Think of it that way: any compiler could have generated the code, and even if VS2012 compiler generated the code, there is no way VS could reverse engineer all the code generation phase to know to which source line a specific assembly command belongs. And with inlining and such, it even adds more difficulty to the task.
So any debugger cannot debug without debug symbols, it is just impossible to reverse assembly semantics into a higher level language semantics (you lose structural information during the compilation process). Otherwise, static analysis tools would be so easy to write.
Edit: .lib file does not include debug information either, just the necessary information to link against it. So you're out of luck too.
Suppose that I compiled a dynamic library (Windows DLL and/or Linux shared object file, .so) in debug mode for use by a client application that links to it dynamically. My source code is available to the client application developer.
I need some clarification regarding the following debugging scenario. I've always understood/assumed that in order for the client application to debug into my library
(for e.g. in order for a client application developer to step into my source code while debugging, say using F10 in MS VC++), that they would have to have actually built a local copy of my libraries themselves (with access to my source code), or atleast have local access to my source code without having built it (not sure if that would suffice?).
Am I right on this? In other words, I think it is not merely enough to provide libraries with debugging symbols (PDB files in MS VC++) if the client application is linking dynamically to my application which has itself been built dynamically. Appreciate if anyone can help sort this out for me? How about the situation in Linux? My understanding again is the same as the above. Now if I had compiled a static library (Windows LIB and/or Linux library .a); my understanding is that the they then don't need to have a locally build copy of my source code (I haven't tried this one out yet)?
Is/are my premise(s) correct? If not, can someone kindly provide some detailed explanation preferably with an example? Thanks for your input.
As requested, here's my comment as an answer. Since it only addresses the Windows side of things, anybody who has the Linux (or Mac!) part of the answer is free to edit it in (I've marked this as a community wiki answer).
For VC++, the debug build DLL + matching PDB + matching source is all you need. The hard part is getting them all to match ;-)
Also, it works more smoothly if the source files are at the same path as when the DLL was compiled, but Visual Studio is also perfectly capable of prompting you to browse to the source manually if you have it.
I have more experience with Windows than linux. But I would think the concept is similar.
if the client application is linking dynamically to my application which has itself been built dynamically.
I'm not quite sure if I understand "building dynamically". You might be confused with the dynamic aspect of dll? dll is linked at runtime (not build time) to allow a part of component to be deployed without a full app. For example, an app on Windows that rely on a dll provided by the OS are not impacted when Windows updates that dll as long as the interface is maintained. The only difference between a dll and exe is that dll's entry function is dllmain as opposed to main in exe.
(The only "dynamic build" concept I can think of is building templated classes. But I don't think that's what you mean here.)
Hence, debugging a .dll isn't different from debugging a .exe, it's just that .dll is a separate binary file from the executable. All the source code provide is allowing debugger to align the stepping with lines in source code. When source code is not available, then debugger can still step through assembly code with symbols.
When situation doesn't allow, then developers who are good at reading assembly code can do debugging with only symbols and no source code.
You can usually build a binary with optimized option, then compiler might optimize the assembly code so much that source code alignment in the debugger might not be possible. This usually happens with released code. In those cases when you step through the code, you sometimes see the line or condition jumps that are seemingly different from what you would expect. There is the same on .exe, .exe with libs, or .dll. This is probably why you thought it is always necessary to build your own binary to debug dlls?
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.