I've been developing a 3D engine for a while, and it was working (on both linux64 and winxp64) when my winxp64 drive stopped booting. I bought a new disk drive, installed 64-bit win7 and vs2010, and now I'm trying to get my engine to compile again. It now compiles, but the linker generates the following errors:

1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_status referenced in function _ig_image_create
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_create referenced in function _ig_image_create
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_image_surface_create_for_data referenced in function _ig_image_create
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_format_stride_for_width referenced in function _ig_image_create
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_surface_destroy referenced in function _ig_image_destroy
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_destroy referenced in function _ig_image_destroy
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_surface_write_to_png referenced in function _ig_image_save
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_get_matrix referenced in function _ig_image_get_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_toy_font_face_get_weight referenced in function _ig_image_get_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_toy_font_face_get_slant referenced in function _ig_image_get_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_toy_font_face_get_family referenced in function _ig_image_get_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_get_font_face referenced in function _ig_image_get_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_move_to referenced in function _ig_image_set_drawpoint
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_set_source_rgba referenced in function _ig_image_set_color
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_set_font_size referenced in function _ig_image_set_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_select_font_face referenced in function _ig_image_set_font
1>igimage.obj : error LNK2019: unresolved external symbol __imp__cairo_show_text referenced in function _ig_image_draw_text

I'm not sure, but I thought the __imp__ prefix on function names implies I'm trying to link to a DLL, not a static library. This confuses me, because the link targets I specify in VS2010 are the following:

opengl32.lib
winmm.lib
ws2_32.lib
glib-2.0.lib
libpng.lib
zdll.lib
cairo.lib
pango-1.0.lib
pangocairo-1.0.lib
freetype239MT_D.lib
fmodex_vc.lib

Maybe I'm forgetting something, but I thought .lib files were static link libraries, not DLL link stubs or whatever. None of the other libraries are generating build errors. Either that or the build process is stopped before it attempts to link additional subsystems.

I quadruple checked my various search directories, and cairo is included. Because I build 32-bit and 64-bit linux implementations and 32-bit and 64-bit windoze implementations (and just copy my whole project directory back and forth between my linux and windoze computers), I created a parallel directory structure for include files, library files, and so forth. They follow the general structure:

/usr/bin/
/usr/include/
/usr/lib/

and inside each of the (usr/bin, usr/include, usr/lib) directories are the expected individual subsystem directories (cairo, pango, freetype, glib, zlib, etc), which contain the appropriate files.

For example, inside /usr/lib/cairo are the following files:

cairo.def
cairo.lib
libcairo.dll.a
libcairo-gobject.dll.a
libcairo-script-interpreter.dll.a

I don't reference any *.a or *.dll.a files in my project settings. I've been creating static builds (or think I have been) since the beginning of this project.

Of course, maybe those __imp__ symbol prefixes don't [necessarily] mean or imply DLLs, and my problem is elsewhere. I'm far from a guru when it comes to building apps in lots of different ways. In fact, I'm not expert on windoze in general, I do most of my work on linux, then just copy over the files and make sure they build and run on win7.

I downloaded my "binary" and "developer" files from <http://www.gtk.org/download/win64.php>, which has been a reliable place in the past. In fact, I've downloaded and copied the include and lib files from the cairo package three times now, trying to fix this problem.

Maybe I'm doing something totally stupid here, but I don't see it. The first time I tried to build this code on win7, VS2010 accepted the old project file and made an upgraded one without errors. And I've looked through the project settings at length and don't see anything obviously wrong (to dimwit me, anyway).

The application builds and runs in both 32-bit and 64-bit mode on linux. But of course that doesn't mean much, since the problem here seems to be in the build process, which is codeblocks and gnu tools on linux, and VS2010 on win7.

Any ideas?

I've given you a -1 for "windoze" because it's rather silly and immature, but - without reviewing your full question - one item of info I cna give is that .lib files certainly can be .dll link stubs, and there are several examples of this throughout various MS SDKs (a .lib just contains code, and there's nothing to prevent that code from making LoadLibrary/GetProcAddress/FreeLibrary calls).

As an aside - any reason to not use Code::Blocks/MinGW on Windows? It seems to me to make more sense to keep your builds consistent in this way than to deal with the hassle of moving between different build environments/processes.

Yes, I would like to develop with codeblocks on both platforms, and maybe someday I will go through the effort to do that. In fact, I was going to make the switch now, but someone (from here on gamedev) wants to integrate my project with a project he is doing, and he is not willing to learn a new IDE. So I'm putting up with VS2010 until I am finished helping him.

One problem with switching is that I have hundreds of #ifdefs LINUX and #ifdef OTHEROS in my code. Right now they serve two purposes... differences between the two platforms/OS, and other differences. In other words, I'm going to need to go look at every one of those #ifdefs and decide whether it needs to #ifdef on the basis of the OS-name, or on some other basis (like toolset: GNU vs VS). I should have been more careful at the start, but I wasn't.

Switching to codeblocks/mingw should help me in another way too. I have 4 separate assembly-language files for 32-bit linux, 64-bit linux, 32-bit VS, 64-bit VS. In theory a single 32-bit assembly-language file in gas syntax should work on both, because the function protocols are the same, so presumably mingw gas should assemble and link the file correctly. I'd still need a separate file for 64-bits, because the function protocols are drastically different. It would still be a lot easier to translate them than currently, since they'd both be gas syntax.

Anyway, so the cairo.lib file might be a static DLL stub file that dynamically links to the cairo DLL file. But my questions still remain. Why doesn't it link? What is that __imp__ prefix all about? Why doesn't it find those symbols? Maybe it is trying to link to the actual function names (as in a static linked library), but only finds those __imp__ prefix names. Or maybe it is the other way around.

BTW, it is you who is incredibly immature. Think about it. Does bad spelling cause you cancer? You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here). You are so petty or hyper-sensitive, I'm a bit stunned.

I'll throw in another vote for using as close to the same environment on all platforms as possible. You never know when a new version of one toolkit introduces an idiosyncrasy that needs a work-around that might cause trouble with another toolkit. If you can focus on making the environment dependable, you can put a better focus on making the code stable.

BTW, it is you who is incredibly immature. Think about it. Does bad spelling cause you cancer? You can't believe how many times I've helped people, and spent a lot of time doing so, and not gotten thanks (or a +1 when here). You are so petty or hyper-sensitive, I'm a bit stunned.

Everybody has fanboy wars, but the bad spelling causing cancer comment strikes me as taking it the wrong way. He likely took reservation against people downplaying another's operating system of choice, not your spelling. That being said, almost none of the quoted section is related to each other. I'm a stickler for spelling, myself, but I believe he's asking you to try to express your opinions in a way that doesn't offend others, or withhold it if that is impossible to do so in order to create an environment conducive for constructive conversation.

Later: I ran the dumpbin.exe program on cairo.lib and libcairo.dll and found the names of the cairo functions (like "cairo_create" and "cairo_destroy" for example), and they did not have __imp__ or __exp__ prefixes on the symbol names. So I'm at a total loss why VS2010 is trying to link in symbols with those __imp__ prefixes. What am I accidentally doing to cause that? I assume it is me who screwed up, but I don't understand. Also, I searched through my program and I don't have a single "dllimport" symbol anywhere. Of course cairo.h or other library files that I include might.

To mhagain: Peace, brother. A two character indirect comment is about as gentle, concise and non-intrusive as one could possibly be. And besides, I type very fast, and that one has been a habit for quite some time. I'm trying to discuss graphics programming problems. It is not me turning 2 characters into flames. I just want to solve this problem and get back to graphics programming, not build hassles.

In case anyone has the same problem someday, and their favorite search engine sends them to this thread, the probable cause of this strange situation is the following.

It appears that somehow I got 64-bit libraries in the 32-bit library directory. Not sure how I could do something that off-the-wall, but when I replaced all the files in my 32-bit and 64-bit directories, the problem vanished. So that was probably the cause.