Hello,
I have noticed that when you install both boost and sdl2 for some strange reason when trying to compile a simple program like:
// ConsoleApplication1.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <SDL2/SDL.h>
int main(int argc, char *argv[])
{
return 0;
}
I get the following error error LNK2019: unresolved external symbol "int __cdecl test_main(int,char * * const)" even if I do not include boost at all.
I think this can be a problem with the autolinking feature of vcpkg as when removing boost completely the SDL2 program is running fine.
I am on Windows 10 anniversary and got into the issue with both Visual Studio 2015 and 2017 RC.
@mattiascibien I have a similar problem with GLEW. I'm doing the leanopengl.com tutorial and decided to use vcpkg for dependencies management. First window and I hit a wall with error LNK2001: unresolved external symbol _glewExperimental. For some reason the IDE sees GLFW .h, .lib, and .dll (present in build output folder) files but only .h in case of GLEW.
I'm on Windows 10 Anniversary and VS2015.
Are you using glew dynamic or statically? Anyway my problem is more related to the fact that when using boost I guess that my main instead of being defined as SDLmain it gets defined as the main of a test for the boost unit testing framework. Not sure why it goes like this actually. From the IDE I find that it is defined correctly.
@mattiascibien Ok, as usual the error was between the monitor an the chair. In the tutorial I mentioned you are supposed to link statically and I did it dynamically. I removed the explicit #define GLEW_STATIC and everything started to work. I'm learning the ropes here (full time JEE dev) so sorry for spamming your post and best of luck.
No worries at all. Welcome to the wonderful world of 3d graphics :-)
Il 27 nov 2016 13:17, Bartłomiej Pietrzyk notifications@github.com ha scritto:
@mattiascibienhttps://github.com/mattiascibien Ok, as usual the error was between the monitor an the chair. In the tutorial I mentioned you are supposed to link statically and I did it dynamically. I removed the explicit #define GLEW_STATIC and everything started to work. I'm learning the ropes here (full time JEE dev) so sorry for spamming your post and best of luck.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vcpkg/issues/352#issuecomment-263119099, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABPYyZTeoHYnn-pIlMmJMSE0Sp74MTGlks5rCXTQgaJpZM4K8-a5.
I'm having a bit of a hard time reproducing this (I get a different error), but we should probably move boost's unit test library out into lib\manual-link\ according to #306.
@ras0219-msft which error are you getting? I will try to test on another machine.
I'm getting
LINK : fatal error LNK1561: entry point must be defined [C:\src\project5\Project5.vcxproj]
Note though that I'm using the Empty Project template with a single source file:
// ConsoleApplication1.cpp : Defines the entry point for the console application.
//
#include <SDL2/SDL.h>
int main(int argc, char *argv[])
{
return 0;
}
Also, @rhinox thanks for mentioning the solution to your issue! This is a place where we'd like to do better in Vcpkg; we should bake that macro directly into the header files based on the exact build configuration so users don't hit these sorts of issues.
Edit: I forgot that SDL2 wants you to link against the "WINDOWS" subsystem (Linker -> System -> SubSystem). When I switch to that, everything links successfully with and without boost installed.
I'm having the same problem (and same error) as @mattiascibien. Looks like both Boost.Test and SDL2 provide the main function (in boost_test_exec_monitor.lib, see here and in SDL2main.lib, see here). SDL2 also provides WinMain, so in subsystem WINDOWS everything works fine. However, when building console app there are two main functions for the linker to choose, hence the errors (I'm not sure why error messages differ though).
If someone is looking for a quick fix, looks like disabling substitution of main works great (#undef main).
it is also possible to delete boost_test_exec_monitor.lib from lib and debug/lib to temporarly fix the issue.
EDIT: as @codicodi said I am now using WINDOWS subsystem. I lost console debug output but I need to setup a file logger and therefore I do not have big problems
It sounds like both the boost test monitor and SDL2main.lib need to be moved into the manual-link directory. How hard would it be to add a check to ensure that the same symbols aren't getting defined in multiple libraries? I'd imagine it'd be relatively expensive to do the actual check (as it's doing a union of every single lib in vcpkg), so perhaps hide it behind a --verify flag or something similar?
Moving those two libs to lib\manual-link is the correct solution here.
This is also certainly something we should detect during a post-build test, along with a pre-install test.
lib\ should be exporting _main or _WinMain.lib\ should be exporting a symbol that another library inside lib is exporting.We can make the test fast by writing out a log of each package's symbols -- we already do this for each package's files under installed\vcpkg\info\*.list. This is what powers the vcpkg owns command and @alexkaratarakis has recently added support for using these file lists to detect package conflicts before installing. We simply should do the same for exported symbols.