Cloning in different location


I see you suggested to clone the project into /home/prog2/project3. However, thats not very practical for me, because if I clone it into the VMs shared folder, I have access on my PC and on my laptop. But then VS seems to get confused with the import path of (at least) the header files, failing to find them unless I provide an absolute path. Is there any way to change the internal path of the includes, or is there something else I have to fear not working if I just include the header files with abs. paths?


You can also clone the project in other folders.
At first, the header files will not be recognized.
But the problem should disappear after running or after the first execution of make.

Please do not use absolute paths in the source files as these paths will be invalid on the server.

Technical detail:
The clang plugin looks for the header files and needs a hint with an absolute path from .clangd. The .clangd file is updated each time make or is executed. But you could also update it yourself.

Thanks for the input, but that didnt seem to fix the issue.

Running ./ and make on a freshly cloned repo yields the following error after executing make:

===> LD bin/wordle_opt
/usr/bin/ld: /tmp/ccvMbWu9.o: in function main': main.c:(.text.startup+0xce): undefined reference to generateDict’
/usr/bin/ld: main.c:(.text.startup+0x13c): undefined reference to `generateDict’
collect2: error: ld returned 1 exit status
make: *** [Makefile:35: bin/wordle_opt] Error 1

with the header files still not being found.

That make fails with an error afterward is intended as the functions are not yet implemented.

Have you closed and re-opened VSCode to apply the changes?

Ah okay, I expected that to be because worlde.h wasnt included as expected.

I did, even after restarting the VM Visual Studio underlines #include "dict.h" red, saying 'dict.h' file not found.
If I (experimentally) include an absolute path for e.g. dict.h, its the same for util.h in the next line. If I clone it into /home/prog2/project3 however, it works instantly.



same for me. All threads I’ve read so far suggest workarounds or bugfixes that do not work for me. It still says, that it can’t find the dict.h header file. I removed this line, just for fun, and it seems like it can’t find any of the files in /include. I did run the patch and make. I even checked the clangd file for correctness. D:

1 Like

You are in the VM, the .clangd file is correct, and you have not deleted the .vscode folder?

What is the exact error reported by VSCode? (From which plugin does the error originate?)

There isn’t an unusual compilation error message, if you meant that. But VSCode is complaining permanently and underlines all include statements, even after I’ve restarted it.

The files are correct, yes. And I did not delete any folder :slight_smile:


If you hover over the error you get a message including the name of the plugin reporting the error.
You can also click “View Problem” to get this information:


Which plugin reports the error? clang-tidy or clang?

Does the path to your project contain spaces?


Seems to be clang-tidy. No, the path does not contain any spaces or special chars (except a dot, but I don’t think that this could raise such an exception).

Ironically, now that David has the same problem, I just tried re-cloning it and now it works. Not that I did this like several times before. I dont know what and if you guys did something, but it seems to be fixed? xD

1 Like

I cloned the files freshly too today, since I had to due to a switch to my laptop, but the error keeps the same for me :sob:

Sorry to ask like that: Are you sure you openened your project root folder in VS Code and not only the /src folder? :smiley: Alternatively, I’d suggest, you shutdown your VM. (Probably if everything fails, try updating your VM?) This might get rid of missing files that may support the changes done for this project.
sudo pacman -Syu. If you think, that some files are corrupt, try: sudo pacman -Syyu

I don’t know if you would have to apply ./ once more after that but executing it another time should not break anything.

Indeed, I was about to ask this. Many of you open the src folder in VSCode for some reason (did we tell you to do this somewhere?). Don’t do this. Instead, open the root folder. Double-check that you have opened the root folder, which you can check by verifying that your VSCode file view shows the src folder like this:


and not like this:


I can only speak for me here, but that’s what I did for sure and multiple times. When I cloned it into the shared folder and opened the root folder in VS Code, the problems occured, cloning into /home/prog2/project3 however worked perfectly fine. One problem I noticed beside the import thing is that VS didn’t seem to see the launch.json file containing the debug configuration, which also worked instantly in the /home path. However, after just giving in and working in /home, it miraculously worked as I tried to reproduce the error, although I did exactly the same.

Hey Nico,

Thanks for your reply. Yes, I opened the root folder, not only the src folder. I don’t think that any file is corrupted, since it is a freshly cloned repo (muliple times freshly cloned). Must be something different :smiley:


Does it make a difference if it is underlined in yellow?
I cloned it in /home/prog2/project3, opened the root directory in VS Code and already applied the patch. But when I save something all include statements are underlined in yellow.

This does not really matter.

1 Like

Okay, thanks!

For the record, having the same problem. Definitely opened it in the project3 directory and have already applied the patch.

Edit: it doesn’t seem to be specific to #include “dict.h” rather the first included library with quotations marks. For example if I put a fake line #include “fake.h” in front of “dict.h” the error goes away for “dict.h” and is replaced with a yellow error.

1 Like