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?
Related
I am migrating Qt to Qt 5.10.1 from VS 2013 to VS 2015. Getting following multiple link errors.
error LNK2001: unresolved external symbol __CxxFrameHandler3
error LNK2001: unresolved external symbol strcmp
error LNK2001: unresolved external symbol __imp__invalid_parameter_noinfo_noreturn
error LNK2001: unresolved external symbol memcpy
error LNK2001: unresolved external symbol _CxxThrowException
error LNK2001: unresolved external symbol __imp_calloc
error LNK2001: unresolved external symbol fabs
error LNK2001: unresolved external symbol __imp___stdio_common_vsprintf
error LNK2001: unresolved external symbol __std_terminate
error LNK2001: unresolved external symbol memset
error LNK2001: unresolved external symbol strlen
error LNK2001: unresolved external symbol __C_specific_handler
error LNK2001: unresolved external symbol _initialize_narrow_environment
Note:In order to migrate to VS 2015, I have right clicked on project and upgraded to latest, in my case VS 2015
In my project following link property was set to "Yes",
I have updated to "No" fixed my link error.
Project->Properties->Linker->Input->IngoreAllDefaultLibraries to "NO"
I was reading this post.
http://www.cpan.org/src/README.html
and
http://search.cpan.org/~rjbs/perl-5.16.0/README.win32#Building
I extracted the files to: c:\Sources\perl-5.26.0\ Now I want to build it.
I set CCTYPE = MSVC141
Now I run:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools\VC\x64 Native Tools Command Prompt for VS 2017
Later:
C:\Sources\perl-5.26.0>win32\Makefile
'win32\Makefile' is not recognized as an internal or external command,
operable program or batch file.
C:\Sources\perl-5.26.0>nmake -f win32\Makefile
Microsoft (R) Program Maintenance Utility Version 14.10.25019.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'config_H.vc'
Stop.
C:\Sources\perl-5.26.0>
With CMAKE:
mkdir c:\Sources\perl-5.26.0\bld
cd /d c:\Sources\perl-5.26.0\bld
cmake . -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX="c:\Custom\perl" -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo
CMake Error: The source directory "C:/Sources/perl-5.26.0/bld" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
c:\Sources\perl-5.26.0\bld>
Sorry I forget to check the existence of: CMakeLists.txt file
Is it possible to build perl instead of obtain downloading from ActivePerl (The installer is not working properly) or Strawberry-perl (the site was down) ?
Please tell me.
How I must define this variables:
MSVCDIR = ???
CCHOME = $(MSVCDIR)
CCINCDIR = $(CCHOME)\include
CCLIBDIR = $(CCHOME)\lib
My Output.
generate_uudmap.c
link -out:..\generate_uudmap.exe #C:\Users\...\AppData\Local\Temp\nmFB0B.tmp
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_exit
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_fputc
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_fopen
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp___acrt_iob_func
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_fclose
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp___stdio_common_vfprintf
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp__errno
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_fputs
generate_uudmap.obj : error LNK2001: unresolved external symbol __imp_strerror
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _seh_filter_exe
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _set_app_type
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol __setusermatherr
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _configure_narrow_argv
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _configure_narrow_argv
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _initialize_narrow_environment
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _initialize_narrow_environment
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _get_initial_narrow_environment
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _initterm
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _initterm_e
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol exit
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _exit
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _set_fmode
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol __p___argc
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol __p___argv
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _cexit
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _cexit
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _c_exit
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _register_thread_local_exe_atexit_callback
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _configthreadlocale
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol _set_new_mode
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol __p__commode
msvcrt.lib(exe_main.obj) : error LNK2001: unresolved external symbol __C_specific_handler
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __C_specific_handler
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _seh_filter_dll
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _initialize_onexit_table
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _register_onexit_function
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _execute_onexit_table
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _crt_atexit
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol _crt_at_quick_exit
msvcrt.lib(tncleanup.obj) : error LNK2001: unresolved external symbol __std_type_info_destroy_list
msvcrt.lib(utility_desktop.obj) : error LNK2001: unresolved external symbol terminate
msvcrt.lib(utility_desktop.obj) : error LNK2001: unresolved external symbol memset
..\generate_uudmap.exe : fatal error LNK1120: 38 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.EXE"' : return code '0x460'
Stop.
c:\Sources\perl-5.26.0\win32>
win32/Makefile does not officially have support for building with Visual Studio 2017. But, it does have support for building with VS 2015. The reason building with Visual Studio 2015 tools require a separate configuration than with building with Visual Studio 2013 tools is the same for Visual Studio 2017 tools, so you can use the same configuration.
To do so:
Open a "x64 Native Command Tools Command Prompt for VS 2017" command window from Start.
Go to the directory in which you extracted the Perl 5.26.0 sources, and edit win32/Makefile:
Set:
CCTYPE = MSVC140
...
CCHOME = C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017
CCINCDIR = $(CCHOME)\include
CCLIBDIR = $(CCHOME)\lib\x64
Noting the version dependent directory in CCHOME. Make sure you use the version that corresponds to what you have.
Run nmake in <perl source directory>\win32. Now, I usually make some more changes, but this is the minimal amount of changes necessary to have a build.
Then, nmake test, nmake install.
Note that perls built with Visual Studio 2015 and 2017 may end up being rather useless because they link with the new platform runtime which OpenSSL does not work with. I think this means you are not going to be able to use modules such as LWP, HTTP::Tiny etc with https. I haven't investigated this a lot, so if I am wrong, I would love to be corrected.
Note that Visual Studio 2013 tools are also installed when you install Visual Studio 2017, so if you can live with certain bugs and the fact that Perl's build config for VS 2013 by default ignores the C99 features included in VS 2013, or if you are willing to hand-edit config files, I have found building with that to be more reliable.
In general, you are better off using Strawberry Perl. Using the MinGW toolchain saves a lot of time if you want to use modules that depend on C libraries.
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 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.
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.