LNK2019 Error with jpeg.lib

I have been trying to add jpeg loading code to an MFC application in Visual Studio 2005. I'm not sure if I'm linking in a bad order or using improper compiler options, etc. I've been poking around for well over an hour, I'm sure this is something minor, but when I add my texture loading code, which uses jpeg.lib, I get the following error:

Quote:

---

1>jpeg.lib(jerror.obj) : error LNK2019: unresolved external symbol __iob referenced in function _output_message
1>.\Debug/Viewer.exe : fatal error LNK1120: 1 unresolved externals

---

Any ideas?

Hmm ... sounds like the library was compiled with an older version of VC++. Did you compile the jpeglib project yourself, or use a precompiled version?

jpeg is precompiled. I've got another project, which was converted from VS2003 to VS 2005, working with the jpeg library, but this MFC project, which I believe was written from scratch in VS 2005, can't take the jpeg code without the linker error, and I'm really not sure which compiler options might have screwed this up.

Try the various options for the C runtime library (static, dynamic, ...). The symbol it complains about comes from there.

I think that with your suggestion I may be on the right track, but I'm not *quite* there yet. I've tried the following suggestions from the following site (with your input as a guide):

http://www.tc.cornell.edu/SoftwarePages/Migrating+to+Visual+Studio+2005+from+Visual+Studio +.NET+2003.htm

Quote:

---

If you prefer static linking (the VS2003 default), do the following for each project in your solution: Go to Properties | Configuration | C/C++ | Code Generation | Runtime Library.

Release: Change /MD to /MT, Multithreaded.
Debug: Change /MDd to /MTd, Debug Multithreaded.

---

These changes belch out errors from afxwin.h:

Quote:

---

afxver_.h(77) : fatal error C1189: #error : Please use the /MD switch for _AFXDLL builds

---

Yes, dynamic MFC linking is incompatible with static CRT linking.

You can try static MFC linking to see if using the static CRT solves your linking problem. However, be aware that static MFC linking makes your application a *lot* bigger. If you have several components that use the MFC, this is not advisable.

Other than the switches mentioned above, what other options might I try changing?

As I see it, I really just ought to find a more recent build of the jpeg.lib, which is what I'm trying to do (I re-downloaded a jpeg.lib but got the same results).

So the reason the other static .lib files linked to this project don't fail is that they weren't compiled with the same C-runtime dependencies as the jpeg.lib? I'm having a hard time actually appreciating what these problems mean (right now they still just seem a bit absurd, and very frustrating).

EDIT:

I went back and re-created the project, instead opting for linking with MFC in a static library, re-compiled, and the JPEG funcitonality is working. But the same code with static creates a 3.17MB executable, and the original project (same exact source, minus the jpeg part) builds an executable of 280KB. That's a pretty significant size difference.

So, do you think I ought to try rebuilding the actual JPEG .lib in VS2005? It'd be pretty nice to not have to needlessly inflate the final binary.

It's certainly an option. Probably the best one. You should be able to get the source of jpeglib pretty easily.

Hey there I just wanted to upload the jpeg.lib static library that works with visual studio 2005, linking to MFC dynamically. When I searched the net I found a lot of people were having something of a similar problem. Just to recap, I could use the 'old' jpeg.lib (presumably built with an older version of visual studio, e.g. 2003 or earlier) only if I linked to MFC statically. This unnecessarily inflated the final binary to about 3 MB, up from only about 200KB.

Also, here are two sites that helped me with the details. I used the first site to get the source (see section 3.3), as well as premade sln. and vcproj files as well as the proper jconfig.h for VS2005.

The second link simply talks about some of the compiler switches that had been changed between when vs 2005 was made (explaining what CornedBeef had talked about earlier).

http://www.spy-hill.net/~myers/help/...n-windows.html

http://blogs.msdn.com/branbray/archi...08/437078.aspx

Links for the files:
http://www.yourfilehost.com/media.ph...eglib_VS2005.h
http://www.yourfilehost.com/media.ph...peg_VS2005.lib