I built ffmpeg 1.2.1 as a static lib - x64, debug. And I tried to open one of my older projects that links against it. After modifying some changed APIs and similar in my source, it compiled fine, but I have major problems with linking.
EDITED: the complete latest build output:
1>libavformat.a(mov.o) : error LNK2019: unresolved external symbol __imp__gmtime64 referenced in function mov_read_mvhd
1>libavutil.a(parseutils.o) : error LNK2001: unresolved external symbol __imp__gmtime64
1>libavformat.a(os_support.o) : error LNK2019: unresolved external symbol __imp__wsopen referenced in function ff_win32_open
1>libavcodec.a(pthread.o) : error LNK2019: unresolved external symbol __imp__beginthreadex referenced in function ff_thread_init
1>libavcodec.a(frame_thread_encoder.o) : error LNK2001: unresolved external symbol __imp__beginthreadex
1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__localtime64 referenced in function av_parse_time
1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__time64 referenced in function av_parse_time
1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__mktime64 referenced in function av_parse_time
1>libmingwex.a(lib64_libmingwex_a-mingw_output_format.o) : error LNK2019: unresolved external symbol __mingw_get_msvcrt_handle referenced in function __mingw_set_output_format
1>libmingwex.a(lib64_libmingwex_a-mingw_get_codepage.o) : error LNK2001: unresolved external symbol __mingw_get_msvcrt_handle
What am I doing wrong? What am I missing here?
Does ffmpeg even work today on Windows platform as a static lib, or it becomes less functional on Windows with each new version?
First 8 errors could be solved by manually inserting
#define _CRTIMP
in some files. This will prevent incorrect use of declspec(__dllimport). We are building a static lib, not a DLL, so it shouldn't be there. I also tried using --extra-cflags='-D_CRTIMP' while running configure before building ffmpeg, but it brakes the build totally. So, manual way is the only way.
The last 2 errors are total bitch:
libmingwex.a(lib64_libmingwex_a-mingw_output_format.o) : error LNK2019: unresolved external symbol __mingw_get_msvcrt_handle referenced in function __mingw_set_output_format
1>libmingwex.a(lib64_libmingwex_a-mingw_get_codepage.o) : error LNK2001: unresolved external symbol __mingw_get_msvcrt_handle
I found these symbols in libmingw32.a (if I remember correctly). But, when I link it, I have conflicts with LIBCMTD.lib. Removing the LIBCMTD.lib creates tons of unresolved externals.So, I would say that today we are not able to build ffmpeg as static x64 lib on Windows. It was in a way expected, because each new version was less Windows friendly.
Related
I am compiling OpenBLAS with Visual Studio 2017, using this tutorial: https://github.com/xianyi/OpenBLAS/wiki/How-to-use-OpenBLAS-in-Microsoft-Visual-Studio#cmake-and-visual-studio. It works perfectly. However, when I try to link to a project that is using OpenBLAS, I have errors during the link.
error LNK2019: unresolved external symbol spotrf_
error LNK2019: unresolved external symbol dpotrf_
error LNK2019: unresolved external symbol spotri_
error LNK2019: unresolved external symbol dpotri_
error LNK2019: unresolved external symbol sgeqrf_
error LNK2019: unresolved external symbol dgeqrf_
error LNK2019: unresolved external symbol sorgqr_
error LNK2019: unresolved external symbol dorgqr_
error LNK2019: unresolved external symbol ssyevd_
error LNK2019: unresolved external symbol dsyevd_
This project was working perfectly with the downloaded binary version of OpenBLAS. The only notable difference is, I changed the include path to the one generated by CMake. And instead of linking to libopenblas.dll.a, I link to openblas.lib, which should be a more Visual-Studio-friendly way of linking...
I noticed that all these functions seems to come from Fortran files. Could that be the reason? And since OpenBLAS seems to be compilable with Visual Studio, how to fix the problem?
As I need to link to static C runtimes I decided to build all as static librarys in question with the same version of Visual Studio (2013) using the same Platform Toolset and Runtime libraries Multi-Threaded /MT
I am trying to get my application to link to a 3rd party game engine. This engine is built on top of libpng and zlib. libpng is also built on top of zlib.
So I build zlib from scratch into a static library.
I then build libpng and point it to the zlib as an additional dependency so zlib gets linked in to my libpng static library.
I then build my game engine linking to both libpng and zlib as additional dependencies. The linker removes the second zlib definition. So far all builds fine.
I then link my application just to my game engine static library. I get linker errors like:
2>libOxygine-vc120-mt-gd.lib(unzip.obj) : error LNK2001: unresolved external symbol _inflate
2>libOxygine-vc120-mt-gd.lib(pngrutil.obj) : error LNK2001: unresolved external symbol _inflate
2>libOxygine-vc120-mt-gd.lib(unzip.obj) : error LNK2001: unresolved external symbol _inflateEnd
2>libOxygine-vc120-mt-gd.lib(pngread.obj) : error LNK2001: unresolved external symbol _inflateEnd
2>libOxygine-vc120-mt-gd.lib(unzip.obj) : error LNK2001: unresolved external symbol _crc32
2>libOxygine-vc120-mt-gd.lib(png.obj) : error LNK2001: unresolved external symbol _crc32
2>libOxygine-vc120-mt-gd.lib(unzip.obj) : error LNK2001: unresolved external symbol _inflateInit2_
2>libOxygine-vc120-mt-gd.lib(png.obj) : error LNK2001: unresolved external symbol _adler32
2>libOxygine-vc120-mt-gd.lib(png.obj) : error LNK2001: unresolved external symbol _inflateReset
2>libOxygine-vc120-mt-gd.lib(pngrutil.obj) : error LNK2001: unresolved external symbol _inflateInit_
2>libOxygine-vc120-mt-gd.lib(pngwrite.obj) : error LNK2001: unresolved external symbol _deflateEnd
2>libOxygine-vc120-mt-gd.lib(pngwutil.obj) : error LNK2001: unresolved external symbol _deflateReset
2>libOxygine-vc120-mt-gd.lib(pngwutil.obj) : error LNK2001: unresolved external symbol _deflateInit2_
2>libOxygine-vc120-mt-gd.lib(pngwutil.obj) : error LNK2001: unresolved external symbol _deflate
It seems to be having a problem finding zlib but this has been linked into libpng, which in turn was linked into the game library libOxygine.
My application itself is not directly dependant on both zlib and libpng so I dont really want to have to link to them directly from my application as it should be all taken care of inside my game engine library libOxygine.
Thanks
If you used .vcxproj project from zlib package, it contains some bugs.
here is instruction for fixing them (i used zlibvc, not zlibstat):
http://www.tannerhelland.com/5076/compile-zlib-winapi-wapi-stdcall/
For fixing the unresolved symbols problem, open zlib project preferences,
then go to Configuration Properties -> C/C++ -> Preprocessor, and in the Preprocessor Definitions line remove “ZLIB_WINAPI;” (don’t forget to remove the trailing semicolon).
libpng depends upon zlib, so you must link libpng first, then zlib. From your error messages it appears that you have them reversed. For example, if you are using gcc to build and link, you need "-lpng -lz" on the commandline, not "-lz ... -lpng".
I've build openssl manually (static libraries) following this guide now when I try to link my MFC test app with libeay32.lib I get following errors:
1>Linking...
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext#4 referenced in function _capi_free_key
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertGetCertificateContextProperty#16 referenced in function _capi_get_prov_info
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertOpenStore#20 referenced in function _capi_open_store
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFindCertificateInStore#24 referenced in function _capi_find_cert
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertEnumCertificatesInStore#8 referenced in function _capi_find_cert
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertCloseStore#8 referenced in function _capi_find_key
1>libeay32.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertDuplicateCertificateContext#4 referenced in function _capi_load_ssl_client_cert
Any advice? Thanks in advance.
EDIT:
I’ve used OpenSSL 1.0.1t source code and Visual Studio 2008 command prompt for building 32 bit static libraries (I had no success with 1.0.2h version). My test app works fine when linking dynamically but I want to be able to link with static lib’s. I’m using OpenSSL for EVP Symmetric Encryption and Decryption
when I try to link my MFC test app with libeay32.lib I get following errors...
You need to configure with enable-capieng. Also see Compilation and Installation on the OpenSSL wiki and How to use CAPI engine in OpenSSL mailing list archive.
error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext#4 referenced in function _capi_free_key
...
Once configured properly, you need to link against Windows' crypt32.lib library. See, for example, CertFreeCertificateContext functions. On Windows, it should be enough to add the following to your MSVC source file:
#pragma comment (lib, "crypt32");
I have been trying to upgrade to wxWidgets 2.9.4 over my old 2.8.12 and have run into problems. I compiled it without errors from the command line but when I try to use them in the program that worked just fine under the previous version I get unresolved externals. I cut it down to just a bare frame and TextCtrl object and it still does this (it's basically identical to one of the sample codes at the moment).
I tried the following commands to build the static libraries:
nmake -f makefile.vc SHARED=0 BUILD=release + nmake -f makefile.vc SHARED=0 BUILD=debug
nmake -f makefile.vc SHARED=0 MONOLITHIC=0 BUILD=release + nmake -f makefile.vc SHARED=0 MONOLITHIC=0 BUILD=debug
nmake -f makefile.vc SHARED=0 BUILD=release UNICODE=0 + nmake -f makefile.vc SHARED=0 BUILD=debug UNICODE=0
nmake -f makefile.vc SHARED=0 BUILD=release UNICODE=0 MONOLITHIC=0 + nmake -f makefile.vc SHARED=0 BUILD=debug UNICODE=0 MONOLITHIC=0
Note that I tried using them with both the recommended unicode and no longer supported non-unicode (changed the project properties in Configuration Properties->General accordingly). Also, I used multi-threaded DLL /MD and /MDd linking as recommended by the wxWidgets manual.
Edit: Tried using \MT and \MTd as well, same effect.
From all of the above I get the same linker errors listed below when compiling my application. Please advise me what to do because I have ran out of ideas...
Additionally, as a final resort I built the whole thing using the converted MSVS project from the ../build/msw folder but it gave me the same results.
Debug compile
1>hworld.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxApp::Initialize(int &,unsigned short * *)" (?Initialize#wxApp##UAE_NAAHPAPAG#Z)
1>hworld.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall wxAppConsoleBase::OnAssertFailure(unsigned short const *,int,unsigned short const *,unsigned short const *,unsigned short const *)" (?OnAssertFailure#wxAppConsoleBase##UAEXPBGH000#Z)
1>hworld.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall wxAppConsoleBase::OnAssert(unsigned short const *,int,unsigned short const *,unsigned short const *)" (?OnAssert#wxAppConsoleBase##UAEXPBGH00#Z)
1>hworld.obj : error LNK2001: unresolved external symbol "unsigned short const * const wxEmptyString" (?wxEmptyString##3PBGB)
1>hworld.obj : error LNK2019: unresolved external symbol "private: static struct wxString::SubstrBufFromType<class wxScopedCharTypeBuffer<unsigned short> > __cdecl wxString::ConvertStr(char const *,unsigned int,class wxMBConv const &)" (?ConvertStr#wxString##CA?AU?$SubstrBufFromType#V?$wxScopedCharTypeBuffer#G###1#PBDIABVwxMBConv###Z) referenced in function "private: static class wxScopedCharTypeBuffer<unsigned short> __cdecl wxString::ImplStr(char const *,class wxMBConv const &)" (?ImplStr#wxString##CA?AV?$wxScopedCharTypeBuffer#G##PBDABVwxMBConv###Z)
1>hworld.obj : error LNK2019: unresolved external symbol "void __cdecl wxOnAssert(char const *,int,char const *,char const *,unsigned short const *)" (?wxOnAssert##YAXPBDH00PBG#Z) referenced in function "public: void __thiscall wxControlContainerBase::SetContainerWindow(class wxWindow *)" (?SetContainerWindow#wxControlContainerBase##QAEXPAVwxWindow###Z)
1>wxpngd.lib(wxpng_pngread.obj) : error LNK2019: unresolved external symbol _inflateInit_ referenced in function _png_create_read_struct_2
1>wxpngd.lib(wxpng_pngread.obj) : error LNK2019: unresolved external symbol _inflate referenced in function _png_read_row
1>wxpngd.lib(wxpng_pngrutil.obj) : error LNK2001: unresolved external symbol _inflate
1>wxpngd.lib(wxpng_pngread.obj) : error LNK2019: unresolved external symbol _inflateEnd referenced in function _png_read_destroy
1>wxpngd.lib(wxpng_png.obj) : error LNK2019: unresolved external symbol _crc32 referenced in function _png_reset_crc
1>wxpngd.lib(wxpng_png.obj) : error LNK2019: unresolved external symbol _inflateReset referenced in function _png_reset_zstream
1>wxpngd.lib(wxpng_pngrutil.obj) : error LNK2001: unresolved external symbol _inflateReset
1>wxpngd.lib(wxpng_pngwrite.obj) : error LNK2019: unresolved external symbol _deflate referenced in function _png_write_flush
1>wxpngd.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol _deflate
1>wxpngd.lib(wxpng_pngwrite.obj) : error LNK2019: unresolved external symbol _deflateEnd referenced in function _png_write_destroy
1>wxpngd.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol _deflateEnd
1>wxpngd.lib(wxpng_pngwutil.obj) : error LNK2019: unresolved external symbol _deflateInit2_ referenced in function _png_zlib_claim
1>wxpngd.lib(wxpng_pngwutil.obj) : error LNK2019: unresolved external symbol _deflateReset referenced in function _png_zlib_release
Release compile
1>wxpng.lib(wxpng_png.obj) : error LNK2001: unresolved external symbol _crc32
1>wxpng.lib(wxpng_png.obj) : error LNK2001: unresolved external symbol _inflateReset
1>wxpng.lib(wxpng_pngrutil.obj) : error LNK2001: unresolved external symbol _inflateReset
1>wxpng.lib(wxpng_pngread.obj) : error LNK2001: unresolved external symbol inflateInit
1>wxpng.lib(wxpng_pngread.obj) : error LNK2001: unresolved external symbol _inflate
1>wxpng.lib(wxpng_pngrutil.obj) : error LNK2001: unresolved external symbol _inflate
1>wxpng.lib(wxpng_pngread.obj) : error LNK2001: unresolved external symbol _inflateEnd
1>wxpng.lib(wxpng_pngwrite.obj) : error LNK2001: unresolved external symbol _deflate
1>wxpng.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol _deflate
1>wxpng.lib(wxpng_pngwrite.obj) : error LNK2001: unresolved external symbol _deflateEnd
1>wxpng.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol _deflateEnd
1>wxpng.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol deflateInit2
1>wxpng.lib(wxpng_pngwutil.obj) : error LNK2001: unresolved external symbol _deflateReset
1>MSVCRT.lib(crtexe.obj) : error LNK2001: unresolved external symbol _main
All errors coming from libpng are due to not linking with wxzlib[d].lib, simply add it to the list of libraries in your project. Or use the recommended way to build wxWidgets projects with MSVC and use auto-linking by prepending -I$(WXWIN)/include/msvc to your compiler header files search path.
The rest of the errors (which you only get in debug build which is suspicious on its own) are due to a mismatch between ANSI and Unicode builds. I don't know which version do you use finally as you seem to have built all of them at one moment or the other but if you use the default build, then you need to have _UNICODE and/or UNICODE defined in your project options.
Finally, to avoid such build mismatches in the future, either do nmake -f makefile.vc clean or use different build directories by using unique COMPILER_PREFIX for each build in the future. This is really not rocket science, you just need to avoid confusing yourself by doing too many things at once. Good luck!
Go to your project's settings and change General -> Character Set property accordingly. If you compiled the wx libs with UNICODE=0 (however recommended value is 1) then you need to use Multi-Byte Character set. If compiled ith UNICODE=1 then set that property to Unicode
As for runtime libs, if you compiled with SHARED=0 then in your project settings you will need to use C++ -> Code Generation -> Runtime Libraries property with 'Multi-Threaded Debug' and 'Multi-Threaded' for Debug and Release build accordingly.
The easiest way is to build wxWidgets libs from Visual Studio (there is a build/msw folder which contains solution file for VS2010) and in your project set the same properties as wx libs projects have.
I had this problem as well. I solved it by changing the setting in:
C/C++ | Language | Treat WChar_t as built in type
to Yes.
Well, here's a nice obscure one. I'm trying to compile the latest open transport tycoon source in Visual Studio 2005. (It's a C++ app that uses zlib, dx8 and a few other fairly common libraries).
I get a few linker errors to do with the freetype dependencies:
Error 1 error LNK2001: unresolved external symbol #FT_Done_Face#4 fontcache.obj
Error 2 error LNK2001: unresolved external symbol #FT_Load_Char#12 fontcache.obj
Error 3 error LNK2001: unresolved external symbol #FT_Init_FreeType#4 fontcache.obj
Error 4 error LNK2001: unresolved external symbol #FT_Select_Charmap#8 fontcache.obj
Error 5 error LNK2001: unresolved external symbol #FT_Set_Charmap#8 fontcache.obj
Error 6 error LNK2001: unresolved external symbol #FT_New_Face#16 fontcache.obj
Error 7 error LNK2001: unresolved external symbol #FT_Render_Glyph#8 fontcache.obj
Error 8 error LNK2001: unresolved external symbol #FT_Set_Pixel_Sizes#12 fontcache.obj
Error 9 fatal error LNK1120: 8 unresolved externals ..\objs\Win32\Release\\openttd.exe
I've downloaded the most recent freetype stable and compiled it (also in VS2005), and put the ft2build.h and freetype include directories into my VS8/VC/include directory, and put the libfreetype2.lib library so compiled into my VS8/VC/lib directory. What could I be missing?
Thanks!
The # sign at the start of the mangled function names show that your fontcache.obj file is expecting these functions to have the __fastcall calling convention, which is unusual as the default calling convention is __cdecl. I suspect there's a mismatch somewhere in the compiler settings used to build the libraries and those used to build the application. See here and here for more information.