help: cannot link cairo into my 3D engine any more

I’ve been developing a 3D engine for a while, and it was working (on both linux and windoze) 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
[FONT=garamond]

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:[/FONT]

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

[FONT=garamond]
[SIZE=3]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.

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:

[FONT=courier new]/usr/bin/
/usr/include/
[/FONT][SIZE=2][FONT=courier new] /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 that great 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 windoze.

I downloaded my “binary” and “developer” files from <http://www.gtk.org/download/win64.php&gt;, 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 windoze.

Any ideas?

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.[/SIZE][/FONT][/FONT][/SIZE]

I don’t dev on Windows (much), but I suspect you don’t have your Windows compile and link environment synced up properly. This is one of the annoyances of developing on Windows. I’m referring to the __declspec(dllimport/dllexport) stuff which must be compiled in properly when linking with a DLL and “not” compiled in when you’re not.

For more details, see (among other places):