I'm currently trying to link the libav libraries with a project on Windows. The project compiles, but when it actually runs, it immediately exits with an error.
I'm using the libraries found here: https://github.com/BtbN/FFmpeg-Builds/releases/tag/latest. I've tried using both the master builds and the 4.4 builds.
And my CMake config is set up as such,
add_executable(CicadaVid FFMPEGTest/CicadaVid.c )
target_link_libraries(CicadaVid avutil)
And just making a call to any function such as,
int main() {
avutil_license();
}
I end up with a return failure immediately. For reference I'm using the win64 builds with a mingW compiler.
Related
I am attempting to run an old program that uses tcl as well as legacy opengl. I managed to link the opengl libraries successfully; however, I cannot seem to get the tcl linker to work. For context, the program I am using came with include and lib folder. The lib folder contains tclstub86_32.lib, tclstub86_64.lib, and tkstub86.lib as well as opengl .libs. The include folder contains two folders: tcl_include and tk_include, which obviously contain all the .c and .h files for tcl and tk. The following pictures show my settings from using project -> build options:
The error I receive when compiling is:
C:\Users\amlut\Downloads\C\tkogl\curve.c|18|undefined reference to `_imp__Tcl_Free'|
And here is the bit of code that is throwing the error:
if (*line != NULL) Tcl_Free((char*)*line);
I am not sure what I am doing wrong here, any help is appreciated. Thank you.
The problem is that the code is apparently linking against the Tcl stub library (an ABI/API adaptor library) but isn't compiling to use that library but rather to use a full Tcl library instead. When building an extension package, using the stub library is a good thing as it means that the resulting code is not bound to an exact version of the Tcl (and Tk) library but rather to a version of the Tcl ABI which has a much longer support cycle.
The fix is to define the USE_TCL_STUBS and USE_TK_STUBS (that has the identical issue; you have just hit the Tcl version of it first) C preprocessor symbols when building; set them both to 1 and recompile. This is done under the Compiler Settings tab in Code::Blocks apparently.
I have been able to write a CMakeLists.txt file that is able to build my C project on Linux, however, I have been having a lot of trouble to build the project on windows. The cmake .. call succeeds, and Visual Studio 2017 project files are generated, but the build then fails siting:
Error LNK1104 cannot open file 'm.lib'. In the CMakeLists.txt file I am using target_link_libraries(MY_EXECUTABLE m) to try and link the math library, which works on linux, but the above error occurs on windows. After some research, it seems to me that math is handled by the mscvr library on windows, not libm as on linux, but I'm not sure how to configure the CMake file so that I can build on both operating system.
Does anyone have an idea on how I could set this up to be able to build in both environments?
Visual Studio does not need or want you to explicitly request linking the math library. You must avoid adding it as a link library when building for Windows. Instead of unconditionally doing target_link_libraries(MY_EXECUTABLE m), then, you might use:
IF (NOT WIN32)
target_link_libraries(MY_EXECUTABLE m)
ENDIF()
I am trying to run the "libwebsockets-test-server" that is installed with the LWS library, but it will not run because "lwsts[31616]: libuv support not compiled in".
I have checked that libuv is installed (1.8.0). I also changed the setting for LIBUV in cmake and recompiled the library.
LWS_USE_LIBUV = 1
How do I get the project compiled with libuv?
I am on Ubuntu 16.04, cross-compiling using arm-linux-gcc. I have successfully compiled programs, loaded them to the embedded board (TS-7800), and run the executable, but not yet with LWS. I am relatively new to Linux and cross-compilers.
Configuring the cmake using 'cmake -DLWS_WITH_PLUGINS=1', changes the configuration to set LWS_USE_LIBUV equal to 1 and compiles libuv with the make.
Since I was planning to use plugins with LWSWS, this was an appropriate fix for the problem.
I am trying to compile native linux c files on windows using GNU GCC compilers. For the installation purpose, I have followed the steps mentioned by Faheem in the following link :
Using GCC(minGW) as Matlab's MEX compiler
the example given there compiled successfully. but when i am trying to compile a file using thread functions, the following error is being thrown:
fatal error: pthread.h: No such file or directory
#include
^
compilation terminated.
I have installed all the components from MinGW installer related to GNU C compiler bu still the error persists. Can any one suggest a way to solve this problem. Thanks in advance.
According to the TDM-GCC "Quircks" page, TDM-GCC includes a pthreads emulation layer for Microsoft Windows systems, called "winpthreads", and a recent toolchain you should have x86_64-w64-mingw32\include\pthread.h in the TDM install path. So, I don't know what is wrong with Faheem's instructions, but you should have no trouble including pthread.h if MATLAB is configured correctly.
What is not stated on the TDM Quircks page is that TDM uses Winpthreads from the MinGW-w64 project. From the current README installed with TDM:
"Winpthreads" is one of the libraries distributed by the MinGW-w64 project, and
it allows GCC to be compiled with full pthreads compatibility, which is
necessary to enable std::thread and other threading related functions in the
C++ runtime.
As it states, Pthreads is part of the MinGW-w64 project and you can also get it with MinGW-w64 if you pick a pthreads enabled toolchain. For MinGW-w64, I do the following to set it up (see here for more details):
Grab the latest revision for w64 from Sourceforge (or use the installer to choose the toolchain you want, picking a pthread version).
Extract it so that you have a path to the compiler like C:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1\bin\x86_64-w64-mingw32-g++.exe. There is no need for MSYS, cygwin, or any other environment if you plan on compiling in MATLAB with mex.
Set it up with a custom mexopts.bat or using the new xml configuration system. On my GitHub repo, I have C++ configurations for MinGW-w64 in both file types: mingw_mexopts.bat and mex_C++_mingw-w64.xml. For example, using the xml file to set up C++ MEX file compilation:
mex -setup:C:\Users\Jon\Documents\MATLAB\mex_C++_mingw-w64.xml C++
If needed, set up the C compiler in a similar manner by modifying the config files.
I posted a more detailed version of the above instructions in my answer to the canonical question on the MinGW-with-MATLAB topic.
I am using OpenSSL-Win32 library on an x86_64 win7 machine, with MinGW gcc compiler. I am linking the libeay32.a and ssleay32.a statically to my program. No warning or error code is generated.
However, after the compiling and linking, the executable file exit with
The application was unable to start correctly, 0xc0000013
I checked my destination executable with dependency walker and it shows
C:\windows\system32\libeay32.lib
is linked to my program! Then I renamed that file to something like ~libeay32.lib and, without recompile my program and reopen it with dependency walker, now
c:\python27\lib\site-packages\pyqt4\LIBEAY32.DLL
is linked to the program. Clearly static library libeay32.a is not working and my program is dynamically searching for the library.