Wait, I didn't think it were possible to be in a worse Dll hell than Windows? You are probably referring to putting dll's in C:\ecs\dll ? or C:\OS2\dll?
Edit: sorry, it's 1am, haha. Case of the Monday.. Tuesday.. damn it. I understand now. The Library should be installed properly, but I've already installed GCC4.3.3 as a wpl. (Properly I think), it's all good. Just happened to use the first google response for libc064. Installed those two wpls and removed all dll files I manually put in.
Remember that windows, and OS/2 are from the same roots.
It has become customary for eCS users to put the base OS/2 DLLs into \OS2\DLL, and to put additional "system wide" DLLs into \eCS\DLL. OS/2 (non-eCS) does not have a \eCS\DLL directory, so they put additional "system wide" DLLs into \OS2\DLL. It is only a way to manage the location, and make sure that duplicates don't exist. They can be anywhere, as long as the location is in LIBPATH in CONFIG.SYS, and the location is permanently available to the system.
It is also customary, but not essential, to keep program specific DLLs somewhere in the program directory. The dot ".;" entry in LIBPATH says to look in the current path (usually the Working directory, as defined in the program icon properties), for DLLs. That way, the DLLs can be found without having to put that specific path into the LIBPATH statement. Also, be aware that some program installers include things like Libc064.DLL (the real one), and they need to be removed so you don't have duplicates.
"DLL HELL" can be the result, if you put something like Libc064.DLL (the real one, not the forwarder) into the program directory (for instance). The program will probably work okay, but that may depend on which Libc064.DLL gets loaded first. Once those things get loaded, they usually never get released, and any other program that needs them just uses what is already loaded. So, sometimes, you may be using the forwarder, and sometimes the real thing. It shouldn't make any difference in that case (but it can). It gets more complicated when you try to run Firefox, and Thunderbird, at the same time. They each have a common DLL name, but the actual DLLs are different. That requires other techniques to work around. The program RUN! is the best answer. Search for RUN! at HOBBES
http://hobbes.nmsu.edu/. I think the instructions should be good. You can also look up LIBPATHSTRICT which changes the rules, but needs to be used properly, or other problems can be caused.