I get the error
cannot find -lpthreadGC2
when building my program. The strange thing is that it is definitly there. I build using cmake, in combinition with Eclipse and MingW. All other libraries work perfectly fine (they are set up in the same way).
With cmake I can use the command message() to give out messages. I checked that all include paths and lib pathes are set correctly with message(). I can confirm this in the Eclipse project settings, the paths are set (including pthreads.h works perfectly, it is found).
The command target_link_libraries(MyApp "libpthreadGC2.a") is also executed (checked again with message()).
Summary: all pathes are set, all linking is ordered to cmake. Eclipse knows all the paths. But the MingW linker doesn't find the library. Any ideas where I should look for the errors?
Ah, just found it out...
The cmake command add_executable() has to come after the link_directories() call... But I still wonder, why this only was for the pthreads lib and not for the others...
Related
I just downloaded and installed Mingw. I also setup the system environment variables for C:\MinGW\bin and C:\MinGW\msys\1.0\bin. I wanted to test to see if I had installed it correctly (it seemed to be since running gcc --version worked), so I wrote hellow world in c and tried to compile with gcc main.c -o hello_world.exe. However I got the error:
"The code execution cannot proceed because libewinpthread-1.dll" was not found. Reinstalling the program may fix this problem."
I have tired reinstalling it and restarting my computer. I have also tried to see if this problem has occurred to others, and while there are a few places it is mentioned, I can't seem to find a solution mentioned. I have thought about trying to download the dll separately, but if I remember correctly, downloading dlls is a big no no.
Awhile ago I installed mingw though chocolatey and it seemed to be working. I have deleted that download from my computer and removed the paths, since I wanted to try to install it the normal way. Could this be part of the error?
Any ideas what the issue could be? Thanks!
You have built an .exe file that depends on libwinpthread-1.dll.
Solutions to make sure the .exe can run:
Add the MinGW bin path to your PATH so libwinpthread-1.dll - this would only fix it for your own system so I wouldn't recommend this if you want to use the .exe file on other systems.
Copy libwinpthread-1.dll from MinGW in the same folder as your .exe file. This is generally needed for any shared dependancy library your .exe is linked against.
Build a static .exe (--static linker flag) to avoid the shared (.dll) dependancy.
Yes! probably is an error, cause MinGW is a bit stinky when it comes to DLLs
Here are some things you have to check:
Make sure the variable helding the location of MinGW is named "path"
and its pointing at: C:\MinGW64\bin
I've been programming C for a while with Visual Studio, but now switched to CLion. My programming and target system is Windows10.
Within Visual Studio, I was able to include the required DLLs like "vcruntime140d.dll" and "ucrtbased.dll" inside my exe.
I did this by going into the project settings and set configuration settings - C/C++ - code generation - runtime library to "Multithreaded-Debug (/MTd)".
Doing this I was able to run the resulting exe without having errors like "vcruntime140d.dll is missing" or "ucrtbased.dll is missing".
But how can I achieve this within CLion?
I've been searching for a while now, and I found a lot of tutorials on how to include .lib files but not for DLLs (I don't have the code for).
With Clion, you actually are working with CMake. So the question is to be like how to link dlls within CMake.
There are many ways to do. e.g.
link_libraries
target_link_libraries
If the library could not be found by default, use find_library to search for it.
If these functions seems too strange to you, check this tutorial from the CLion team.
Update
As in the comment you asked, your problem is how to load a dll without lib. To address this, you could dynamicly load the dll, or make a lib from the dll.
For Windows multicopies problem, add following into your CMakeLists.txt
foreach (flag_var
CMAKE_C_LINK_FLAGS
CMAKE_C_LINK_FLAGS_DEBUG
CMAKE_C_LINK_FLAGS_RELEASE
CMAKE_CXX_LINK_FLAGS
CMAKE_CXX_LINK_FLAGS_DEBUG
CMAKE_CXX_LINK_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS_RELEASE
CMAKE_C_FLAGS
CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_RELWITHDEBINFO)
string(REPLACE "/MD" "-MT" ${flag_var} "${${flag_var}}")
endforeach ()
I've downloaded the portaudio codebase and compiled it fully with source, and installed it to my system with these commands:
./configure
make
sudo make install
But XCode is complaining to me, even when I put -lportaudio in the Other Linker Flags for the project settings.
I've researched this problem and tried whatever I could find on Stack Overflow, but there was no decisive answer that would work for me. Any advice on how to fix this?
I'm using an older version of XCode and haven't bothered looking at how the interface might have changed in the newer versions, but this is generally solved for me by modifying the User Search Paths under your project settings. Look at the screenshot, add /usr/local/include to Header Search Paths and make Always Search User Paths "Yes." That should do the trick
Edit:
One more thing to note, this is only /usr/local/include because that's the default install directory for the portaudio.h file in the portaudio build (as it is with many libraries).
If you have a different prefix other than /usr/local/include, add that instead.
I am using CODE::BLOCKS in windows XP. Tried to write a device driver. But right after creating a project, I got below error. I did below settings, but still getting the error as
"ntddk.h no such file or directory". I have tried with all compilers (Project built option), but it is still there.
Please help.
Created the project like:- File->New->Project->Kernel Mode Driver->Next->Next...
If, like most people using Code::Blocks on Windows, you use MingW-TDM (commonly detected as "GNU GCC Compiler" by Code::Blocks, and bundled with the "easy install" package), the file ntddk.h is located in the ddk subfolder of the system include folder.
Thus, you either have to add the ddk folder to the include search path, or write #include <ddk/ntddk.h>, either will work.
Your list of compilers does not seem to include the DDK compiler
Do you have the windows DDK installed?
NOTE: I know nothing about codeblocks but you will need the DDK compiler to compile windows drivers.
UPDATE 1:
My original post was too long and obscured the real problem. I have discovered exactly what is causing the "Multiple targets" bug when Make is called.
UPDATE 2:
I found out that this 'Multiple Targets' bug is caused by GNU Make version 3.8.1 (see here1 and here2). GNU Make 3.8.1 is the current GNU Make released with Cygwin. To summarize the link: The old v3.8.0 handled windows paths fine and the newer v3.8.1 reports errors for windows paths (maybe it's a passive aggressive jab from the FSF?).
When you start a new project in Eclipse+CDT+Cygwin w/o external includes/libraries, everything works fine for me.
As soon as I try to use an external include/library I get the "Multiple targets" bug.
Here is exactly the steps needed to reproduce the bug on Windows+Eclipse+CDT+Cygwin:
Project project properties --> C/C++ Build --> Settings --> Tool Settings --> Cygwin C Compiler --> Includes --> Include Paths (-I) -- > Add Button --> Pick directory --> "C:\dir1\dir2"
I hit build.
It builds with no errors the first time.
I hit build again... I get build errors "Multiple targets. Stop.".
I click on the error.
Eclipse pulls up a makefile. The error happens when make sees the windows path for the new include file from the external library:
# NOTE: Error happens when the first "C:/" occurs
src/main.d src/main.o: ../src/main.c C:/dir1/dir2/ExternalLibrary.h
The reason for Make getting an error "Multiple targets" is because it sees the ":" which is part of the Make syntax for declaring a target. When there are two ":", Make errors out because it doesn't know what to do with "Multiple targets."
I can not edit the makefiles manually because they are immediately regenerated and overwritten [UPDATE: by Eclipse-CDT]. Given that I can't manually edit the makefile.
Is there any way for Eclipse to NOT use the "C:\" path? or tell make to ignore the "C:\" path?
Is this an Eclipse+CDT+Cygwin bug?
If you use Eclipse+CDT+Cygwin... please lend a hand (I don't want to use Visual Studios...)! Maybe I am using Eclipse+CDT+cygwin wrong? How do YOU get External Library includes to work?
*Very very frustrated*
Trying to stay Open-Source and cross-platform user,
Trevor
Turns out the "multiple targets" issue is caused by the current version of GNU Make installed from Cygwin. GNU Make 3.8.1 is the current GNU Make released with Cygwin.
The GNU Make 3.8.1 does not handle windows paths that contain "C:\". So every time your make file has a windows path with "C:\" you get a build error "multiple targets".
The solution I ended up doing is to download a fixed GNU Make v3.8.1. See Here1 or Here2. Then Eclipse+CDT+Cygwin worked fine again.
Update (05-feb-2015):
With an updated cygwin and a new Make (4.0.x) then the problem goes away.
https://superuser.com/questions/154418/where-do-i-get-make-for-cygwin
Had a such a problem, too. Problem was that I included paths on the project settings. Then I had absolute paths. When including the paths in the folder settings with relative paths it worked fine.
I still Got the same problem with eclipse/CDT Juno after update cygwin
to fix it:
you need make 3.80-1 or older and this needs cygintl-2.dll.
download make3.80-1 from
http://www.filewatcher.com/m/make-3.80-1.tar.bz2.286814-0.html
and the needed Dll from
http://www.dllguru.com/cygintl-2.dll.html
extract it somewhere
rename your make in cygwin/bin to makeVersion e.g. make3.82.90
copy cygintl-2.dll and make into cygwin/bin
try build your project in eclipse twice, the problem should be disappeared
gerdi