How to link allegro 4.4 with visual studio 2010 - c++

I have been trying for several hours now to link allegro 4.4 with visual studio 2010. I am using microsoft visual C++ 2010 express edition. Here is what I did:
I downloaded the windows binaries from http://www.allegro.cc/files/?v=4.4 (I downloaded the MSVC 2010 one)
I extracted the three folders in the zip archive to the following location "C:\allegro"
I launched MSVC and created a new windows console application
I created a main.cpp file
In the project properties I went to VC++ directories and set Include Directories to "C:\allegro\include"
In VC++ directories I set Library Directories to "C:\allegro\lib"
In Linker->Input I added "allegro-4.4.2-md.lib" to the additional dependencies.
In Configuration Properties->Debugging I set 'enviorment' to "PATH=c:\allegro\bin;%PATH%"
I applied all the changes and entered this simple program into main.cpp
#include <allegro.h>
int main()
{
return 0;
}
END_OF_MAIN();
When I tried to debug it I got two errors Error 1 error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup and Error 2 error LNK1120: 1 unresolved externals
I've been pulling my hair out in frustration! Can someone please help me out or point me in the right direction?

Well I feel like an idiot now but I figured it out after reading http://www.allegro.cc/manual/4/miscellaneous/frequently-asked-questions-(faq)/windows-problems/d4cf0624ded68003a11b4892102bbc66. I realized the problem is that I created a console application rather than a window application. I fixed this by going to Configuration Properties -> Linker -> System and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)" I hope this helps any else who runs into this problem.

You need to add this
Project Properties->Linker->Input->Additional Dependencies: edit and add the following
alld.lib

Related

Using vcpkg with Visual Studio 2022 produces a bogus unresolved external symbol linker error

I have an MFC C++ project, which builds and runs just fine with Visual Studio 2022 on Windows 10. The project doesn't use Qt at all. After I installed Qt 6.2.1 with vcpkg, project stopped building with this linker error:
1>Qt6EntryPoint.lib(qtentrypoint_win.cpp.obj) : error LNK2019: unresolved external symbol main referenced in function WinMain
Again, there is no usage of Qt6 in my project. Going to project's Configuration Properties and disabling Use Vcpkg makes it build again. What is going on here and how to fix it without disabling vcpkg?
I created a new C++ MFC App with VS project wizard and default settings. It builds fine with vcpkg enabled.
The only reasonable explanation I can offer is that many generations ago, older VS, older Windows, my project was using a few classes from Qt4 core for a while, which caused problems, so that functionality was removed. I continued to develop it on Windows without Qt installed. Is it possible that some reference to Qt is still lurking around? How to find it? I checked settings several times and couldn't find any.
I looked at the order of library search (/VERBOSE:Lib) and with vcpkg -> Use Autolink enabled, vcpkg folders are searched first. Is there a way to make the linker search system folders first?
Here is what's happening:
1> Searching C:\src\vcpkg\installed\\x64-windows\lib\Qt6EntryPoint.lib:
1> Found WinMain
1> Referenced in msvcrt.lib(exe_winmain.obj)
1> Loaded Qt6EntryPoint.lib(qtentrypoint_win.cpp.obj)
Excluding Qt6EntryPoint.lib with /NODEFAULTLIB:"Qt6EntryPoint.lib" has no effect. Is there another way to exclude it?
This means you should open up an issue in vcpkg.
Qt6EntryPoint.lib needs to be moved into the /manual-link subfolder.
(I really hate the lazy MSBuild autolink/link everything feature of vcpkg.)

Trying to use regsvr32 registered DLLs in VS 2019

So here's the issue:
I have an old software system written in C++ and built originally on Win Xp with VS 2005 SP1. Most of the solutions in this code-base are reliant on third-party DLLs that are registered using regsvr32.exe. Without this step VS 2005 throws out Linker errors. After registration everything works like a charm.
I've been able to successfully rebuild the project using Win 10 and VS 2005 and now I'm trying to do the same with newer version of VS, namely VS 2019. For a single test solution I was able to resolve compilation errors, but it seems that VS 2019 Linker cannot find DLLs that should have been registered with regsvr32, since I'm getting the same Linker errors that I have have been getting with VS 2005 prior to registering DLLs.
I'm most certainly sure that this is due to VS 2019 "not seeing" DLLs that were registered with regsvr32. Thus the question: does anybody have any idea how to make VS 2019 discover those DLLs?
DLLs and target for compiler are 32bit. I've been using SysWOW64\regsvr for registering 32 bit DLLs. The folder with DLLs is in $PATH. Also the folder with DLLs is set in Project -> Project Properties -> VC++ Directories -> Library Directories setting of VS 2019
Edit:
Linker Errors in both cases (before using regsvr32 with VS 2005 and with VS 2019) are of form:
...
1>RecordSet.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall IDatabase::~IDatabase(void)" (__imp_??1IDatabase##QAE#XZ) referenced in function "public: void * __thiscall IDatabase::`scalar deleting destructor'(unsigned int)" (??_GIDatabase##QAEPAXI#Z)
...
Followed by fatal error LNK1120: 17 unresolved externals
I'd be glad to get any pointers.

VS 2017 Community gets linker errors but Professional doesn't

We're facing a strange issue and I've run out of troubleshooting ideas. The issue is that on some machines, which are running Visual Studio 2017 Community, we get reports that our project (which is CMake based) gets linker errors like this:
17>------ Build started: Project: ndt, Configuration: RelWithDebInfo x64 ------
17> Creating Library E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.lib and object E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.exp
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol edKJPOs664VT referenced in function "void __cdecl CheckLibraryLicenses(struct NodeInput*,...)
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol zzPIPSGJWa referenced in function main
...
17>E:\NDT_3_0\19_sep18\qualnet\bin\exata_so.exe : fatal error LNK1120: 17 unresolved externals
(Apologies if there are typos: for some reason they sent us a screenshot of the text instead of just a copy-and-paste of the text, so I'm transcribing. However, the parts I'm leaving out contain no mention of errors trying to open lmgr.lib which defines these symbols.)
The strange thing is, we can't reproduce these errors here when we do a fresh clone of the same Bitbucket repository they're using and follow the same build instructions. About the only difference I can tell is that our machines are running Visual Studio 2017 Professional. (Though I'm certainly not sure if this is actually the cause of the behavior differences.)
So far, what we've checked:
The library that contains the unresolved external symbols passes sha1sum checks so their Git client isn't corrupting the library binary file lmgr.lib - and same for the ndt-main-windows-x64-vc14.obj file.
The generated ndt.vcxproj project contains (the correct path to) lmgr.lib in the "Linker -> Input -> Additional Dependencies" property, as expected.
The lmgr.lib file does define the mentioned symbols (verified by Cygwin binutils nm).
On their machines, they get essentially the same linker errors whether using the Visual Studio 15 2017 Win64 generator and building from the IDE, or using the NMake Makefiles generator and building from a command prompt. Both configurations work fine on our machines.
I was wondering if somebody out there might have any ideas on why some machines might be failing to find the symbols in lmgr.lib whereas our machines have no problems completing the link stage.
(Possibly relevant: lmgr.lib contains the FlexNet Publisher licensing libraries where the symbols in both lmgr.lib and ndt-main-windows-x64-vc14.obj have been obfuscated by Flexera's lmstrip tool.)
It turned out that when we asked them to upgrade their Visual Studio 2017 Community installation to the latest service pack release, then after that the linker errors disappeared.

LIBCMTD.lib(crt0.lib) LNK 2019 error in project

I've created an OpenGL (GLEW) project in VS2012 and it is working perfectly. Now I've moved the project to VS2013. I've created a new project and set the project's environment the same as I did in VS2012:
Character Set:--------------Use Multi-Byte Character Set
Include Directories:--------C:\Foo\glew-1.9.0\include
Library Directories:--------C:\Foo\glew-1.9.0\lib
Additional Dependences:-opengl32.lib; glu32.lib; glew32.lib
Runtime Libary:-------------Multi-Threaded Debug (/MTd)
All code is exactly the same as before, but when I run the program, I get this error:
Error 1 error LNK2019: unresolved external symbol _main referenced in
function ___tmainCRTStartup c:\FooBar\...\Projects\OpenGL\OpenGL\LIBCMTD.lib(crt0.obj)
OpenGL
I can't see why this same project with the same settings and code doesn't work when it is an exact duplicate.
Hi #SpicyWeenie LIBCMTD is the debug version of the static multi-threaded C runtime library, and according to Microsofts licensing you cannot use than in the release version of code, I would check you are compiling in debug mode:
in debug mode use /MTd as the runtime library
in release mode use /MT as the runtime library
This will hopefully help, if not, then clean your project before building, and if that does not help either, apply liberally with swearing before creating a new project and ensuring it is a Windows Console Application and not a Windows Application (the last one has been the most common cause of the exact error you are describing for me, and happens mostly to me when moving between versions of Visual Studio (2008 to 2010 or 2010 to 2012)
Sincerely hope this helps, but if it doesnt let me know and maybe I can figure out whats wrong:)

Native C++ project cannot compile in release mode?

I was building a win32 static library project and on debug mode it compiles without any problem but when I changed the build mode to release I get this link errors. Can anyone suggest what is going wrong here?
Error 2 error LNK1120: 1 unresolved externals C:\Users\serak\Desktop\Cimg Wrapper\Release\nativeWin32console.exe nativeWin32console
Error 1 error LNK2001: unresolved external symbol _main C:\Users\serak\Desktop\Cimg Wrapper\nativeWin32console\MSVCRT.lib(crtexe.obj) nativeWin32console
I think in the Project Propierty Pages (rigth click the project in VS solution explorer) of the project change for ALL configuration and platform, the Configuration Propiertie->Project Defaults->Configuration Type-> from Aplication to Static Libraries: you probably have set it for debug but not for the release configuration.
If you're using Visual Studio, you need to add any external libs that you are linking against in release mode as well. Chances are you have already done this for the debug build configuration, but it does not transfer to release by itself.