I inherited a substantial amount of code, including a visual studio project that is supposed to (as best as I can tell) build a .lib file. Visual studio says "... Generating Code... Creating Library... Creating browse information file...", and at the end, it says the build succeeded. In the release/debug folder, it has a bunch of .obj files, but it doesn't have a .lib file. What could I be missing?
Thanks!
Open the Project Properties (right-click the project in Solution Explorer, select 'Properties'). Under 'Librarian', check 'Output File' - that's where the output should go.
If this looks right, try dir /s *.lib in a suitable subdirectory for your project, to see if you can locate the output library by date and time. If you still can't find it, try a clean rebuild (right click project, select 'Rebuild').
For DLLs, a .Lib file is not created if the DLL exports nothing for external usage. I don't think this applies for static lib builds but I would make sure you are exporting something public from your library project source code.
.lib will not get generated if you miss to add prefix __declspec(dllexport) for methods.
My static library contains nothing but two template classes, so I didn't have a .cpp file. This caused Visual Studio 2015 to not output a .lib file. To solve this, I made a file huh.cpp which includes all of the headers.
I had the same problem, even though I was already using the __declspec(dllexport) function.
Your ProjectName.cpp file needs to #include "ProjectName.h". If you don't include the header file then the functions don't get exported. The DLL builds fine, no errors or warnings (at least in VS2017 15.8), but you don't get a LIB file.
Include the header and boom - LIB file is generated. A rookie mistake I'm sure, but everyone has to start learning somewhere.
If the Methods you want to export are in a class, you have to __declspec(dllexport) on the class. Otherwise no .lib will be created.
In my case (Visual Studio 2019), when #include "pch.h" was not the very first include statement in cpp, lib file was not created.
I just ran across this problem as well.
It was due to using an invalid macro in the output directory definition. In my case, it was
when it should have been
I had to blank out the full path in the second screen shot. I had an incorrect macro. I was using MsBuildProjectDir when I should have been using MsBuildProjectDirectory. The read-only text box will show the full path (eg: C:\Development\blah\blah\blah\) when the output directory is valid. If the output directory is not valid, you'll get something like the first screenshot.
In the DLL project, put __declspec(dllexport) beginnings of methods defined in .h and .cpp files.
After all, compile your dll again, so .lib file will be generated and ready for linking.
put Class Foo
{
public:
__declspec(dllexport) int GetFoo() const;
I was exporting a class from the dll but had declared the class inline in .h file. The .cpp file was there but empty. This setup was causing the .lib file to be not generated.
I moved the implementation of functions to .cpp file and now lib file is generated.
This is in VS2019.
Had the same issue here with VS2019. In my case I had built a few times with no symbols defined (i.e. cpp files were empty).
After I added symbol definitions into the cpp files I began to notice this issue (no lib file was being generated).
A simple clean via 'Rebuild all' fixed it. Perhaps if you build whilst there are no symbols defined, something gets cached somewhere that you have an empty product DLL, and you need to clean the solution to reset that cached state.
My issue was that in the projects Properties>C/C++>CommandLine, I had specfied the switch incorrectly.
That is instead of writting /D_HASHING_BUILD_DLL I had written /D_Hashing_BUILD_DLL.
Side note:
This is how I build my DLL/Lib files in Visual studio : (and my Hashing.h looks like this: )
#ifndef HASHING_H
#define HASHING_H
/* If we are we on Windows, we want a single define for it.*/
#if !defined(_WIN32) && (defined(__WIN32__) || defined(WIN32) || defined(__MINGW32__))
#define _WIN32
#endif /* _WIN32 */
#if defined(_WIN32) && defined(_HASHING_BUILD_DLL)
/* We are building Hashing as a Win32 DLL */
#define HASHING_API __declspec(dllexport)
#elif defined(_WIN32) && defined(HASHING_DLL)
/* We are calling Hashing as a Win32 DLL */
#define HASHING_API __declspec(dllimport)
#elif defined(__GNUC__) && defined(_HASHING_BUILD_DLL)
/* We are building Hashing as a shared / dynamic library */
#define HASHING_API __attribute__((visibility("default")))
#else
/* We are building or calling HASHING as a static library */
#define HASHING_API
#endif
//your inlcudes
class HASHING_API MyClass
{
//...
};
#endif // !HASHING_H
and in the path I stated earlier, I just use the switch I defined here and there you go, the DLL is built just fine!
I'm not so familiar with C++ and I had the same issue. I thought I would share what worked for me. It appears that the import/export must come after the class statement, according to the following page.
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4091?view=msvc-160
// Warning C4091
// No error but didn't produce a .lib file
__declspec(dllimport) class X {};
// __declspec attribute after the class or struct keyword
// applies to user defined type worked
class __declspec(dllimport) X3 {};
Sometimes when you break you head in a new project why .lib is not created - it can be some "past games" issue.
I was creating a new .dll but before I decided to use #define with __declspec(dllexport)/__declspec(dllimport) I tried to play with .def
After removing .def file it probably left some misconfiguration in the project file and it wasn't creating .lib file...
Till I decided to just remove the project completly and recreate - and walla, works perfectly!
Related
I'm trying to reproduce an issue, so I have created an empty MFC C++ application using the VS2019 wizard and a separate native Unit Test project.
Before adding the Unit Test project, the MFC application compiled and launched successfully.
The MFC application still compiles successfully, but the Unit Test project will not compile. I'm getting two errors:
E0035 #error directive: "include 'pch.h' before including this file for PCH"
C1189 #error: "include 'pch.h' before including this file for PCH"
However, the only file in the Unit Test project (UnitTest1.cpp) already includes pch.h at the top of the file:
#include "pch.h"
#include "CppUnitTest.h"
#include "../MFCApplication1/MFCApplication1.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace UnitTest1
{
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(TestMethod1)
{
CMFCApplication1App app;
bool result = app.InitInstance();
Assert::IsTrue(result);
}
};
}
It seems to be telling me to do something that is already done.
What's going on here?
Try to include stdafx.h and remove pch.h, it resolves the issue
I had the same issue. I found that I could not include the MFC DLL project's default header file directly. In your example this would be #include "../MFCApplication1/MFCApplication1.h"
I eventually found this example MFC DLL project code: https://github.com/Microsoft/VCSamples/tree/master/VC2010Samples/MFC/advanced from a list of examples here.
Notice that in the example that the default header/implementation files created by the MFC DLL project creation wizard (in this example, DLLScreenCap.h) don't export or provide any additional functionality. An existing MFC DLL project that I work with did the same.
So I added a class to the MFC DLL project to be tested and exported a simple function from it, and tested this exported function from my unit test project after linking to the project under test.
Exported class and function look like this:
#pragma once
class __declspec(dllexport) MFCLibraryExports
{
public:
// tests returning 17 to test unit test library against an mfc project
int SampleExport();
};
In your example I know that you are trying to test an instanced app and my answer doesn't help with that, but I was able to confirm that I can test at least a function exported from an MFC DLL project using the MS Unit Test framework. I'm not sure if you are expected to be able to get access to the application from a unit test as in your example; I am not able to include that header directly.
I am working with Qt and Cryengine in visual studios. I am very new to large projects such as this one, but I am nearly to the point of actually adding something to this engine. My code compiles piece by piece, but when I try to compile my "Indie Game" project I get linking errors that after researching I still have no idea how to solve. I know the errors relate to my code InventoryGUI, because when I remove that file the project compiles fine with no linking errors.
This is my InventoryGUI code and the error that is displayed when trying to build Indie Game
http://imgur.com/hzmGdvH
This is the header file that it includes.
http://imgur.com/o22GHXg
I appreciate any help you guys can give on this. Of course, if you need to see different parts of my code, let me know and I will post it as well.
Thanks
Edit: Forgot to add that the function "createInventory()" calls the function InventoryGUI from a different project. I believe going between projects is very likely the cause of the errors.
if InventoryGUI class is defined in a shared library ("dll") and used in an executable, then you have to export its symbols (on Windows build that is).
so try something like :
#ifdef WIN32
# ifdef MY_LIB_EXPORTS
# define MY_LIB_DLL __declspec(dllexport)
# else
# define MY_LIB_DLL __declspec(dllimport)
# endif
#else
# define MY_LIB_DLL
#endif
class MY_LIB_DLL InventoryGUI
{
...
};
Then, the library defining InventoryGUI should have defined MY_LIB_EXPORTS.
For example if you use pro files system, it would look like
DEFINES += MY_LIB_EXPORTS
Other projects should not.
Check if there is a similar mechanism for the other classes of the library.
First of all i am a beginner in visual studio so please forgive and guide me if i m going wrong in some way , i am a java and php programmer so i am not new to programming
i want to develop a application which reads fingerprint , i use this device
http://www.egistec.com/en/sensors/fingerprint-es603wb.aspx
which i think uses Windows Biometric Framework , so i tried to run the code mentioned in this page
http://msdn.microsoft.com/en-us/library/windows/desktop/ee207405(v=vs.85).aspx
this is what i did
#include "stdafx.h"
#include "Windows.h"
#include "Stdio.h"
#include "Conio.h"
#include "Winbio.h"
int _tmain(int argc, _TCHAR* argv[])
{ HRESULT CaptureSample(); }
you can find the function CaptureSample() in the second link provided above.
As you can see in the they said to link Winbio.lib, i know that its a dll in system32 , i did some research and created a Winbio.def file and Winbio.lib file,
Now my problem is i dont know how to link the lib file , i added "Winbio.lib" in properties >>LInker >> Additional Dependencies
it shows me the following error
*error LNK2019: unresolved external symbol _WinBioOpenSession#28*
infact this error appears even if i remove it from Additional Dependencies
please tell me where i am going wrong , should i place the lib file in any specific directory ? should i copy the dll somewhere ? or something else ?
Linker > General > Additional library Directoreis
put the path to the lib
Linker > Input
Put the lib name.
You can find this if you do some googling.
If everything is fine and still does not work, very probable that your lib file is not generated correctly. You can then try use dynamic loading of your dll file.
http://msdn.microsoft.com/en-us/library/ms810279.aspx
First loadLibrary is called to get a handle to your dll, then getProcAddress is called to get the pointer to the function. Cast the pointer into the target function defined in your h file. Then you'll be able to call the function.
I had the same problem. Following steps helped me on VS 2015 Community Edition
Right click on the project > Properties.
Linker > Input > then in the Addition Dependencies put winbio.lib; to front
I'm trying to use code that already works in another standalone project without problems.
When I bring this code into my other final project, it indicate that 'cmath' file not found.
The file with the #include is in an .hpp file (it just defines some structs for opengl stuff), so there is not a corresponding .mm file. (This is C++ code and I'm mainly an objective-c user so not sure of all the c++ stuff)
But this is for opengl stuff and works fine we not in this project.
I've tried everything to make this work.
The final project with the problem has other code that uses #include without problems.
It is almost like something is causing xcode not to recognize the path the header anymore.
I've checked its file type it is "Default C++ header"
In the final project I'm using Zxing and also using CorePlots. Not sure if they are causing any problems. Also some file are using #include not sure if that could conflict with the #incude or not. (But again the other files with #include are working fine.
Any help will be greatly appreciated...
Alternately to Jon Reid's good advice you can pick "Compile as Objective-C++" in the Build Settings. (Search for "Compile sources" in the Build Settings window.) This is a little bit wild-west but is a quick way to see if the problem is in fact your C++ source compiling as C or Objective-C
Your header file doesn't exist by itself; something must import it. Rename the importing files, changing their file types from .m to .mm.
For example, let's say your header that includes <cmath> is named foo.h. And that this in turn is used by a bar module, composed of bar.h and bar.m. So foo.h is imported in either bar.h or bar.m.
Rename bar.m to bar.mm so that it uses C++. Do the same for all .m files that depend on foo.h.
when I create an xCode project with the 'Command Line Tool' c++ stdc++ template, i am able to include and compile opencv headers and run some code.
But i want to use OpenCV in a 'Cocoa Application' context. When created with that template, i got compile errors when I include the OpenCV headers in main.mm. (I already changed main.m to main.mm, the '//NSApplicationMain(argc, (const char **) argv);' is commented out)
One of those errors is: "Statement-expressions are allowed only inside functions"
I suppose its some kind of compiler version error, but when i compare the project build settings i cant find differences.
Do you have any ideas/expertise?
I ran into the same problem, I spent 2 days doing serious system tracing and as expected, the solution was so simple that an 8-year-old could have found it more quickly than I did.
Ready for this?
In the .mm file where you want to use OpenCV, you need to do your #include "opencv2/opencv.hpp" BEFORE any other includes. That's it! Just move it up a line and watch your problem magically disappear faster than that rug that really tied the room together.
This is for OpenCV 2.2 by the way, hence the new include file. Also if your XCode project uses a prefix header file (look in "Other Sources" for a "YourProjectName_Prefix.pch" file), then you'll need to put your #include "opencv2/opencv.hpp" there instead of in any other file.
Ian Charnas's Answer is correct, but there is one modification I would make.
This article has a more specific solution, and an explanation of why you need to do this.
http://aptogo.co.uk/2011/09/opencv-framework-for-ios/
// Add this new section BEFORE the #import statements for UIKit and Foundation
#ifdef __cplusplus
#import <opencv2/opencv.hpp>
#endif
Even if you rename your "main.m" to "main.mm" and moving the "#include opencv2/opencv.hpp" to the top (in the main file), the preprocessor will insert cocoa.h first because of the precompiled header files nemed something like "_Prefix.pch". To avoid such problems
- delete the #import statement or
- insert an #import statement above the cocoa.h import statement
Try adding: -lstdc++ to the "Other linker flags" in the build settings for your Cocoa app.
A cocoa application made by the Xcode templates won't link include the c++ library in it's settings by default.
add this to your .pch file
#ifdef __cplusplus
#import <opencv2/opencv.hpp>
#endif
dont forget to convert all of your .m files into .mm files
You'll probably find it easier to use OpenCV's C API rather than the C++ API. You can call C APIs directly from Objective C of course, so this makes life a lot easier. You just lose some of C++'s syntactic sugar, like default parameter values.