0

I am trying to build AV1 codec source code in MS visual studio 2015. When I am compiling aomdec.lib, its getting compiled properly but when I turned it into executable, I am getting some linker errors to the functions which belongs to the standard library (like stdio.h. etc).

The errors are as follows:

severity    Code Description    Project File    Line    Suppression State
Error   LNK2019 unresolved external symbol __imp__fseek referenced in function _file_is_obu aomdec <filename>


Severity    Code    Description Project File    Line    Suppression State
Error   LNK2019 unresolved external symbol __imp__getenv referenced in function _TestEnv    aomdec <filename>

and many more errors in the same fashion.

Can someone tell what is wrong with configuration.

Ghansham
  • 448
  • 5
  • 19
  • There should be another linker error that tells you that you have a bigger problem. Project > Properties > C/C++ > Code Generation > "Runtime Library" setting. – Hans Passant Apr 06 '18 at 14:28
  • @Hans Passant, Thanks for suggestion. I have changed it to MultiThreaded DLL, and it works fine. But i don't understand what it actually means. I am building this library to be used as a static library for another client program. But once I link client to this static library I am getting again similiar kind of errors as mentioned in question. Can you please elaborate what it exactly means and what could be the issue? – Ghansham Apr 06 '18 at 15:04
  • 1
    The /MT option is useful only for very small programs that do not use any DLLs. It links the CRT into the program, not something that ever can come to a good end when a DLL has its own copy of the CRT. You'll end up with nasty very hard to debug problems like having multiple copies of `errno` whose values do not agree. Some libraries have an option to use /MT anyway in spite of those problems, directed by a #define. You have to dig a bit to see if this one has one. – Hans Passant Apr 06 '18 at 16:13

1 Answers1

0

This link might help. As you can see, there are several reasons for the error. What might be happening in your case (since this is a library you're simply building from code that you didn't write) is that you may not be selecting the right options for static building. The right static building options should include function definitions in the library (static library). When you build as DLL, the definitions are in the DLL file instead of the static file (even though a .lib file is generated when you build as DLL, you will notice this .lib file is smaller in size than one when it's a statically built). Note that I'm referring to when building the library that you want your client to use, and not when building the actual client.

When building the client that will use the above built library, if you do a static link from client executable to the .lib file that is generated when you build the library as DLL (above), you will get a linkage error, but if you link the client executable to the same .lib as DLL it should be fine, provided that when you run the client executable you also include the DLL that was produced along with the .lib.

wes
  • 1
  • 2
  • DLL is preferred because it will keep your client executable small and it's easier to deploy a bug fix of the library (because you don't have to rebuild your executable again). – wes Apr 06 '18 at 16:02