Your IDE is codeblocks, what compiler\Linker do you have? (I bet gcc?)

I've had issues with ld.exe before, you need to specifiy the finding path with -L.

Hope it helps!

Editr:

+After a lot of sessions fixing my own linker I found few solutions:

My linker uses the convention <dllname>.dll.a

So try to generate or get files with such names.

+ Maybe you are trying to use libraries built for windows via VS, something that did fix it,

Recompiling the libraries on your own, especially glew or if you use glfw3.

I've even tried copying the .dll into the folder to bypass and when I put -lglew32 in the linker section it just dies. It's very frustrating:

This raises an immediate alarm. The DLL is completely irrelevant at link time, what you need to care about is the corresponding .lib file (or .a file, depending on which naming convention was followed during build).

Technically you can just skip glew and SDL2 altogether and just use the win32 api on windows and X11 on linux and mac. For a beginner tutorial not recommended. You will have to manage getting SDL2 dll's on every users computer to run your exe though.

I'm not sure why glew is needed. I don't see it used in the tutorial source code.

This dude -link below- explains in his video that the GLEW files are precompiled for visual studio and not minGW so that's why they won't work:

While static libraries compiled for one compiler are usually not compatible with libraries compiled by another compiler that is not always the case (for example gcc and clang are meant to largely inter-operate). At the same time even within the same compiler you can have incompatibilities.
The most common example is MSVC and the used runtime. Usually you will need two version of a library (one linking to the Debug and one linking to the Release runtime). Mixing them will (depending on the circumstances and version of MSVC) not work at all or cause highly subtle but ultimately fatal bugs. Apart from that MSVC allows you to chose between two different runtimes (each with a Debug and Release variant) and there are even compile flags/definitions which can make compiled incompatible.
Note that for a pure C library (like GLEW is) this would normally not matter but most prepared MSVC-packages I have seen are set up in a way that they will still cause subtle issues by pulling in the wrong standard library if mishandled.
Linking dynamically largely alleviates the problem (provided the library has properly designed pure C interface) but having to distribute possibly another runtime library just because the library was compiled in the wrong way is extremely annoying.

He gives links to pre-compiled files -link below- for minGW so you can get it running, how frustrating!

I would strongly recommend you get into the habit of building libraries you use yourself. First, it is extremely good practice, second at some point you be in a position where you will need to do that anyway: You might be using MSVC 2013 but the library you need to use is only available precompiled for MSVC 2008 or any other scenario. You might also need to use compile settings which are uncommon and break the ABI.
I have personally seen how wrong things can go if you rely on prebuilt files, even straight from the creators. For example I once ran into a severe trouble with pthread because of this. Despite the fact it's a pure C library the prebuilts from the official site link dynamically to the C++ runtime which is unfortunately not mentioned anywhere, nor the version. Long story short, the whole program failed in a cryptic way on some customer machines until I compiled it myself under known parameters.

One more issue is that if you use the pre-compiled files then they might be for a different version of windows and still cause errors.

e.g.
glewGetErrorString@4 could not be located

That is highly unlikely. That probably means someone compiled the library wrong.

Do I need GLEW or can I just use SDL2 and run all input and sound through that? What's the difference between them as I'm not really sure why I'm wasting my time and sanity trying to get GLEW working.

You will need something like GLEW on Windows. Windows does not give you anything more than OpenGL 1.1 (which is not really enough to do anything fun and interesting) and everything else has to be queried over the extension mechanism. That is a lot of boring work. I would also advise against trying to muck around with function pointers (and all the interesting problems that can happen when you cast them to the wrong type) if dealing with library linkage already gives you so much trouble.