Hi,
I'm using Windows XP with Microsoft Visual Studio 2003. I've tried to get the libjpeg (vers: 6b) example running (example.c). But it crashes during the call of jpeg_read_header.
Has anyone an idea what to do or where to search for an answer?
Thanks,
J
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot!
That was exactly the problem. I'm now compiling with mingw g++ and it's working. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-12-11
This is just an educated guess, but I am pretty sure this is what happens:
Using the jpeg_stdio_src() or jpeg_stdio_dest() functions requires that the calling code and libjpeg use the same C library. Recall that on Windows, there are several C libraries: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, crtdll.dll, and various static libraries.
File descriptors (the small integers returned by open() and stored inside the FILE struct) are in reality an index into a table local to the C library. A file descriptor returned from one C library has no meaning (or a completely different meaning) in another C library.
The libjpeg library distributed by gnuwin32 is built against the msvcrt.dll C library, because that is the one that mingw (the compiler gnuwin32 uses) targets by default, and that C library is part of the Windows operating system and present on all Windows machines. The other libraries come with the Microsoft compilers (but are redistributable as far as I know).
Visual Studio 2003 is as far as I know not even capable of producing code that would use msvcrt.dll (At least not without some severe undocumented and unsupported hacking.) It produces code that uses either msvcr70.dll (or msvcr71.dll?), or its static C library.
Thus, when the code you compiled in example.c calls fopen(), the returned FILE struct contains a file descriptor that has meaning only to the same C library that your code uses.
Passing the FILE pointer to libjpeg won't work. When libjpeg then uses msvcrt.dll to read from the file, it will fail because the file descriptor you passed to it has no meaning (or happens to refer to some completely different file opened by that C library).
You should complain to Microsoft for selling you a compiler that isn't capable of producing code that uses the C library they bundle with the operating system. Ask for your money back, and switch to using the GNU compiler.
Or, recompile the libjpeg library to use the same C library as your other code does. If you build a DLL, make absolutely sure to use a different name for the DLL, though, than what gnuwin32 uses.
Or, don't use the jpeg_stdio_src() and jpeg_stdio_dest() APIs, but other ways to feed data into libjeg. There are several.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm using Windows XP with Microsoft Visual Studio 2003. I've tried to get the libjpeg (vers: 6b) example running (example.c). But it crashes during the call of jpeg_read_header.
Has anyone an idea what to do or where to search for an answer?
Thanks,
J
Thanks a lot!
That was exactly the problem. I'm now compiling with mingw g++ and it's working. :-)
This is just an educated guess, but I am pretty sure this is what happens:
Using the jpeg_stdio_src() or jpeg_stdio_dest() functions requires that the calling code and libjpeg use the same C library. Recall that on Windows, there are several C libraries: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, crtdll.dll, and various static libraries.
File descriptors (the small integers returned by open() and stored inside the FILE struct) are in reality an index into a table local to the C library. A file descriptor returned from one C library has no meaning (or a completely different meaning) in another C library.
The libjpeg library distributed by gnuwin32 is built against the msvcrt.dll C library, because that is the one that mingw (the compiler gnuwin32 uses) targets by default, and that C library is part of the Windows operating system and present on all Windows machines. The other libraries come with the Microsoft compilers (but are redistributable as far as I know).
Visual Studio 2003 is as far as I know not even capable of producing code that would use msvcrt.dll (At least not without some severe undocumented and unsupported hacking.) It produces code that uses either msvcr70.dll (or msvcr71.dll?), or its static C library.
Thus, when the code you compiled in example.c calls fopen(), the returned FILE struct contains a file descriptor that has meaning only to the same C library that your code uses.
Passing the FILE pointer to libjpeg won't work. When libjpeg then uses msvcrt.dll to read from the file, it will fail because the file descriptor you passed to it has no meaning (or happens to refer to some completely different file opened by that C library).
You should complain to Microsoft for selling you a compiler that isn't capable of producing code that uses the C library they bundle with the operating system. Ask for your money back, and switch to using the GNU compiler.
Or, recompile the libjpeg library to use the same C library as your other code does. If you build a DLL, make absolutely sure to use a different name for the DLL, though, than what gnuwin32 uses.
Or, don't use the jpeg_stdio_src() and jpeg_stdio_dest() APIs, but other ways to feed data into libjeg. There are several.