3

Though this is my first question on the StackOverflow, I consider myself a long time member of the community.

Considering myself as a pre-intermediate programmer, I'll try to be as specific as possible.

I'm writing a Python package that uses a C dll to load image files with ctypes. I'm using Python 3.3.5 32bits version on Windows 8 x64. I had to build the dll from the C code. The dll is stb_image.h which is available in GitHub. I used Code::Blocks version 13.12 with the GCC compiler. The dll seems to have built fine.

By my definition, the dll is must be in the same folder as the py code file that wraps its functions, but when ctypes attempts to load the dll an exception is raised: the [in]famous WindowsError: [Error 126] Module not found.

I've found several similar questions and attempted to glean from their solutions by

  • adding the dll path via os.environ['PATH']

  • adding the dll path manually in the Path environment variable

  • changing the current working directory with os.chdir()

  • using the file module attribute to locate the library

none of these solved the issue

The stb_image library itself has no dependencies so I don't understand why windows can't find it since the dll is where it should be and the path addresses it's exact location. And, of course, there's a lot of other ways to get the job done: PyGame, pySFML (which also uses stb_image), PIL, PyPng, PySDL, you name it, but I'm doing this mostly for learning purposes.

At the writing of this question, something popped up in my head (which may or may not have any relation with the problem): whenever I compile and link programs with GCC and try to run them, I got a message box telling me that some dll (libgcc.dll or something like that) was not found. Could that be the reason Windows can't load stb_image.dll?

I tried everything my experience allowed me to do to solve it but it was not enough. Would you guys, please, give me a light on this?

PS.: Sorry for any bad english. I'm natural from Brazil.

joe.dawley
  • 466
  • 4
  • 14
Gomes J. A.
  • 1,235
  • 2
  • 9
  • 9
  • Ultimately the answer to this is likely going to be straight forward (Windows needs to be able to find your DLL as well as any DLL *yours* depends on, any they depend on, etc). I just had to uptick this because for a first question this is stellar, with only the title not phrased as a question being its weak point. Your intuition about the failure to find/load libgcc.dll propagating into a failure to load your DLL is likely spot-on. There is a high probability this is a duplicate to some other question, but I had to comment on how well it was written. nice job. – WhozCraig Oct 16 '14 at 19:56
  • Have you looked at http://stackoverflow.com/questions/10411709/windowserror-error-126-when-loading-a-dll-with-ctypes as a possible solution? – uesp Oct 16 '14 at 20:15
  • @WhozCraig: I found at least 7 or more other questions with this same problem, but some of them are somewhat old and most of them where problems related with the Path environment var. Maybe my case goes a little beyond that.The fact I built the dll without help of other was the main reason for posting this question; I'm not sure if I did it right. – Gomes J. A. Oct 16 '14 at 22:27
  • It sounds like your DLL is built correctly, but simply cannot resolve all its own dependencies at load time, and thus fails to load.Maybe libgcc isn't installed correctly on your platform. Could be any of a host of possible reasons (thus why you found so many potential dupes). A crack at a [dependency walker](http://www.dependencywalker.com) on your finished DLL may help narrow down what appears to be missing. Be sure and use the correct bitness of dependency walker (32bit if your lib is 32bit, else 64bit, you get the idea). – WhozCraig Oct 16 '14 at 22:30
  • I have to thank you @WhozCraig and uesp for point out the possible solution for this. And I apologize too, as this question seems to be more a duplicate than a specific case. I was focusing too much on wrong side of the problem. As the comments above sugests, it was, really, the absence of LIBGCC_S_DW2-1.DLL on my system that was causing the problem. As a childish reaction to this I decided to build the dll using VS2010 compiler, wich gave me one million more warnings than GCC's but a dependency free DLL. Maybe, when I get a little less angry, I'll go after this libgcc_s_dw2-1.dll. – Gomes J. A. Oct 16 '14 at 23:44
  • See this answer: http://stackoverflow.com/a/18650202/235698 – Mark Tolonen Oct 18 '14 at 01:43

0 Answers0