A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
You don't. For regular builds, the only .obj files that your project interacts with is the ones generated from your source files. Anything else is obtained from the .lib files that you set the project to link to.
While there is a little more to it, a .lib file is an archive of .obj files. Think of it as a .zip file if you wish. So setting the linker to the .lib file is enough to provide any extra .obj files that the build requires. This means that if you are seeing any linker errors referencing .obj files then either the SDK that you have downloaded is bad, or you have set something bad as linker input. For example, you have set glut.dll/glut32.dll as a linker input instead of glut.lib/glut32.lib.
If you are trying to link against a DLL, then you must always link against the import library and not the DLL. But this is an utter guess since you haven't given your actual settings.
This is also not something written out of ignorance. Just for testing purposes, I have set up a project to use the old GLUT builds, and generally they are fine. There are some 3.7 builds that are bad, but they just give the unresolved symbol linker error.