librelist archives

« back to archive

undefined external symbol when building on Win32 (C++)

undefined external symbol when building on Win32 (C++)

From:
Dave Brotherstone
Date:
2011-12-14 @ 21:45
Hi,

I'm trying to build a very simple test program under Win32 C++ (Visual C++
express).  I've built libgit2 using CMake, and run the install target.

In my project, I added the lib directory to the Additional Library
Directories, and the include dir to the Include Directories.  git2.lib is
listed as an additional dependency for the linker.
The program compiles fine, but won't link -

gitstatus.obj : error LNK2019: unresolved external symbol
_git_repository_free referenced in function _main
gitstatus.obj : error LNK2019: unresolved external symbol
_git_repository_open referenced in function _main

According to depends.exe, git2.dll exports _git_repository_open@8, and
_git_repository_free@4, which seems right, but I could be missing something.

The only thing that strikes me as odd is common.h seems to define
GIT_EXTERN as __declspec(dllexport), I would expect that to be
__declspec(dllimport) when I include it from my project in order to use the
__imp__ forms of the functions from the link library.  Changing that didn't
achieve anything though.

I've tried it with development HEAD (16a9f32) and v0.15.0.  Many thanks for
any pointers you can give - I know I've probably missed something simple.

Congratulations on a brilliant project - I've used the .NET wrappers before
and everything just worked, and the little app to correct the case of a
filename was finished and working in no time.

Cheers,
Dave.

Re: [libgit2] undefined external symbol when building on Win32 (C++)

From:
Vicent Marti
Date:
2011-12-14 @ 21:56
Hm. This is indeed weird. What's the calling convention for your
project? Note that libgit2 builds by default with `stdcall`, which is
the same thing that the CRT uses. Try disabling `stdcall` on the
Makefile, or switching your project to use it.

Cheers,
Vicent

On Wed, Dec 14, 2011 at 10:45 PM, Dave Brotherstone <davegb@pobox.com> wrote:
> Hi,
>
> I'm trying to build a very simple test program under Win32 C++ (Visual C++
> express).  I've built libgit2 using CMake, and run the install target.
>
> In my project, I added the lib directory to the Additional Library
> Directories, and the include dir to the Include Directories.  git2.lib is
> listed as an additional dependency for the linker.
> The program compiles fine, but won't link -
>
> gitstatus.obj : error LNK2019: unresolved external symbol
> _git_repository_free referenced in function _main
> gitstatus.obj : error LNK2019: unresolved external symbol
> _git_repository_open referenced in function _main
>
> According to depends.exe, git2.dll exports _git_repository_open@8, and
> _git_repository_free@4, which seems right, but I could be missing something.
>
> The only thing that strikes me as odd is common.h seems to define GIT_EXTERN
> as __declspec(dllexport), I would expect that to be __declspec(dllimport)
> when I include it from my project in order to use the __imp__ forms of the
> functions from the link library.  Changing that didn't achieve anything
> though.
>
> I've tried it with development HEAD (16a9f32) and v0.15.0.  Many thanks for
> any pointers you can give - I know I've probably missed something simple.
>
> Congratulations on a brilliant project - I've used the .NET wrappers before
> and everything just worked, and the little app to correct the case of a
> filename was finished and working in no time.
>
> Cheers,
> Dave.

Re: [libgit2] undefined external symbol when building on Win32 (C++)

From:
Dave Brotherstone
Date:
2011-12-15 @ 05:38
On Wed, Dec 14, 2011 at 10:56 PM, Vicent Marti <vicent@github.com> wrote:

> Hm. This is indeed weird. What's the calling convention for your
> project? Note that libgit2 builds by default with `stdcall`, which is
> the same thing that the CRT uses. Try disabling `stdcall` on the
> Makefile, or switching your project to use it.
>
>
Yes, that was it - switching my project to stdcall fixed it.

Many thanks for your help.

Cheers,
Dave.