I'm trying to use the FFMpeg libraries in a Windows application. I use MingW-w64 to compile FFMpeg with static libraries with architecture once with x86 and once with x86_64.
Currently I'm trying to link the 32bit x86 libraries with my VS2008 application.
The libraries are added to the library path and VS does not complain about being unable to load a .a file.
However I get several uneresolved symbol errors like
ait_rtp_receiver.lib(ait_decoder_lib.obj) : error LNK2001: unresolved external symbol _av_free
I import the FFMpeg header files as extern C and I can see the symbols in the .a without the leading underscore.
What can I do to make the name decoration of Mingw-w64's gcc and of the VS compiler suite compatible?
After spending miserable days trying to get the GCC-Mingw based version of building FFMpeg to work, I reverted to using the Visual Studio or Windows SDK compiler and linker. Using the --toolchain=msvc of the configure script made the build process generate static .a files that are basically .lib files that can be loaded within Visual Studio projects.
I wrote the build steps up and here is a link
Related
I like windows gcc equation.com because it like ran natively just like windows compiler. However :
I will need some dll's that not included on distributed package. if i compiled a windows equation.com gfortran program like using Openblas, it will need libgcc_s_seh-1.dll libgfortran-5.dll libquadmath-0.dll libwinpthread-1.dll.
I could find it on web. But how to make it statically linked, i saw libgcc.a libgfortran.a libquadmath.a libpthread.a so i dont have to copy the dll from other. It is possible ?
For several c source code it need include <sys/resource.h> that not included. It's compatible with resource.h from where. After just copied from others, and recompile.
I got error :
c:\gcc\x86_64-w64-mingw32\include\sys\resource.h:74:29: error: unknown type name 'id_t'; did you mean 'pid_t'?
Is there any forum for this type gcc? Is there any debugger for windows gcc that friendly like VisualStudio Community for Intel Fortran.
Regards.
Im trying to make CMakeklist.txt file on Windows and I have big problem.
I wrote
cmake_minimum_required(VERSION 3.1.2)
project(c_api)
set(INC_PATH target/release/deps)
set(PROJECT_DLL traffic.dll)
set(PROJECT_LIB traffic.dll.lib)
configure_file(${INC_PATH}/${PROJECT_DLL} ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
include_directories(${INC_PATH}/include)
add_library(traffic UNKNOWN IMPORTED)
set_property(TARGET traffic PROPERTY IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_DLL})
set_property(TARGET traffic PROPERTY IMPORTED_IMPLIB ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_LIB})
file(GLOB SOURCES "c_api/examples/ai_module/*.c")
add_executable(ai_module
${SOURCES}
)
target_link_libraries(ai_module traffic )
I run the project that CMake generate i got
LNK1107 invalid or corrupt file: cannot read at 0x2D8
I thought that the problem is add_library(traffic UNKNOWN IMPORTED) but if I change it to add_library(traffic SHARED IMPORTED) I get
LNK2019 unresolved external symbol _traffic_import_osm referenced in function _main ai_module
so I assume that Visual Studio dont see a library.
I run this code on linux and i only change the .dll format for .so and it works fine.
Im using Visual Studio 15 2017 on CMake
According to the documentation of your first error, it appears you are trying to link to the .dll directly. On Windows, shared libraries require two files. The shared .dll, which includes all the definitions of the functions and classes in the library, and the .lib which (when build with the dll) only contains the declarations. The stub .lib file is used at compile time to tell the linker what to expect from the function.
Do you have both the .lib and the .dll? If you do not have the .lib, you cannot link the .dll to your program.
I solve the problem. CMake make project of 32bits and my .dll is 64bit and now its work
I have installed MingW GCC 4.8.1 in my system. I am trying to build the LLVM source code( with some extra modification). Cmake 2.8.12 is used to generate the makefiles and visual studio solution files. I am able to build the LLVM source (Rel 3.4.2) with Visual Studio 2010 And is generating both lib and dll file. But with MingW I am not able generate .lib files by simply running Make all.
How to make MingW generate .lib file while building the project ?
Use CMAKE_GNUtoMS. Add -DCMAKE_GNUtoMS=ON to the build command. See this CMake issue. As result, a .lib file will be generated along with the .dll.a file.
I have a Visual Studio 2010 C++ project that links statically to tinyxmlSTL 2.5.5 (tinyxmlSTL.lib) and zlib 1.2.7. (zlibstat.lib). There are 4 builds in total covering both x86 and x64 as well as Debug and Release.
All combinations produce working builds except for Release x64 which gets a bunch of errors like this:
MSVCRT.lib(MSVCR100.dll) : error LNK2005: free already defined in LIBCMT.lib(free.obj)
...and a single warning:
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
If I add /NODEFAULTLIB:MSVCRT to linker options for the application then I get this:
zlibstat.lib(ioapi.obj) : error LNK2001: unresolved external symbol __imp__ftelli64
zlibstat.lib(ioapi.obj) : error LNK2001: unresolved external symbol __imp__fseeki64
Basically, all the projects (app and two libs) are set to use Multi-threaded (/MT) option in Release builds and yet x86 builds just fine while x64 suffers from above issues.
Any help or idea is highly appreciated.
You need to double check your settings for x64. One of the projects is using the /MD flag rather than /MT.
As per the MSVC docs, The MSVCRT.lib is invoked by using /MD.
EDIT :
As per your comments, it sounds like zlib is the likely culprit.
zlib has both a static and dll version, but both of these use the /MD flag by default, so unless you changed that while building zlib - that's your issue.
To build zlib using /MT:
If you've not already done so, install CMake
Download and extract zlib to e.g. C:\devel. The download links are about halfway down the homepage. Currently this provides zlib version 1.2.7.
To work around this CMake bug, add
if(CMAKE_SIZEOF_VOID_P EQUAL 8 AND MSVC)
set_target_properties(zlibstatic PROPERTIES STATIC_LIBRARY_FLAGS "/machine:x64")
endif()
to the end of C:\devel\zlib-1.2.7\CMakeLists.txt
In a VS10 command prompt, cd C:\devel\zlib-1.2.7
cmake -H. -Bbuild -G"Visual Studio 10 Win64"
This gets you a VS sloution C:\devel\zlib-1.2.7\build\zlib.sln which you can open. Change the settings for the "zlibstatic" target to /MT and /MTd for Release and Debug respectively.
Building each will yield zlibstatic.lib in a subdirectory of build; either "Release" or "Debug".
In the project properties for ALL projects, check that they all use the same runtime type: either DLL or static
This can be found under Project Properties -> C/C++ -> Code Generation -> Runtime Library. Make sure you have the Release x64 build selected.
The particular value isn't very important (in terms of compile errors) but they should all be the same
I know you say that all your libs are linking with /MT but that error suggests that one of them isn't. Re-check that the correct libs are being linked with the x64 Release build.
Using gcc 4.5.0 under MinGW, I am trying to build a Windows console executable which links to a static library created with Visual Studio. The static library seems to have dependencies on Visual studio symbols which aren't available under MinGW. Error messages:
undefined reference to `_ftol2_sse'
undefined reference to `_allmul'
Is there a replacement for these functions under MinGW or can this by fixed by setting an additional linker flag?
You will have to explicitly link with the right version of the MSVC runtime. GCC defaults to a different version.