Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 2 of 2

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

Hybrid View

  1. #1
    Intern Contributor
    Join Date
    Jan 2008
    Location
    phobos, mars
    Posts
    75

    Question 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


    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.

    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 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>, 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.
    Last edited by bootstrap; 01-08-2013 at 02:43 PM.

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,213
    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):

    * http://stackoverflow.com/questions/5...e-linker-in-vc
    * http://www.opengl.org/discussion_boa...card-can-it%29
    Last edited by Dark Photon; 01-09-2013 at 06:35 AM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •