Open NPTP opened 4 years ago
Strange, it looks like it's not linking in references from the standard library. Can you try making a simple VS project that uses basic string functions and see if that compiles?
Also, another TA pointed out that this could be due to a conflicting GLFW installation in your path. Make sure that libigl is linking with the GLFW library built locally.
If you don't know how, here are the steps:
In Visual Studio, go the the glfw
project and look at the Source Files
for glfw
. Let us know where those files are located. If it's inside the assignment repo, then it's ok. Otherwise, you need to remove your existing GLFW installation from the system path.
We regularly build and test all assignments on Windows 10, MacOS, and Ubuntu. It is expected to work on all common systems.
Thanks for everyone pitching in to help with this!
Strange, it looks like it's not linking in references from the standard library. Can you try making a simple VS project that uses basic string functions and see if that compiles?
I can build such a project (using #include <cstring>
and the strcpy
function) with 0 errors. Also, I was able to build and run all the assignments with the same setup, up until A5. Rather than spend time trying to fix it, I just started working in the labs instead.
Make sure that libigl is linking with the GLFW library built locally.
How might I go about this?
In Visual Studio, go the the
glfw
project
Hi, thanks for the tips. Do you just mean here?
If so, these are the only options I get on a right-click:
Not sure how to find the glfw
"project" and Source Files
!
Thanks!
That confirms my assumption that cmake is finding a pre-installed glfw on your system and using that. Let's try this fix:
./CMakeLists.txt
and add this line after cmake_minimum_required(VERSION 3.1)
:
set(MSVC_RUNTIME "dynamic")
CMakeCache.txt
from ./build/
.cmake ..
and then rebuild from VS.If this doesn't work, then we can try other fixes to try to make sure that cmake doesn't use the pre-installed GLFW.
That confirms my assumption that cmake is finding a pre-installed glfw on your system and using that. Let's try this fix:
That did it! I can build + run now. Thanks so much for your help, I really appreciate it!
The images I shared, those views haven't changed since applying the fix. Which part of the last post clued you in that cmake was definitely linking the wrong path of glfw? Just curious to try to understand this IDE better!
Yeah, that's because the fix I gave still doesn't use the GLFW included with libigl. It's just making sure the rest of the assignment is linked dynamically with the C Runtime library. Your original screenshot suggested that the GLFW you were using was being linked dynamically with the C Runtime. Normally, libigl forces anything using it to link ~dynamically~ statically with the C Runtime on Windows. This is needed for a component of libigl that we never use for this course. Since we never use that component, it's perfectly acceptable to link the runtime dynamically.
I see. That's helpful - thanks again!
just leaving this open in case someone else has this problem
Hi,
For the past few assignments (since libigl was introduced) I haven't been able to get any builds working at home on Windows (Win7 x64, Visual Studio 2019), and have had to work on them exclusively in the CDF labs. Of course the labs are now closed so I need to find a way, but I haven't been able to manage it.
On a fresh recursive clone of the repo, I invariably get the following errors when trying to build (same errors for dense/sparse executables):
I've been searching online for a solution but nothing has worked yet. If anyone has any ideas or pointers to things that helped them, let me know. Thanks!