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
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 was having a lot of trouble getting code completion to work in QtCreator 3.0.1 on ubuntu 14.04.04LTS.
I went to the QT creator website and downloaded the latest version 3.6.1 and I think I've identified the issue but don't know how to fix it.
To replicate, I go to "File|New file or project|Non-Qt project|Plain C App
Then make a test.c file, qmake build system, i leave the "desktop kit" checked, and start.
As you can see here:
It can't find stdio.h
But if I specifically write:
#include "/usr/include/stdio.h" everything works!
The only place i can find an include path to search is in Tools|options|C++|File Naming -> Search paths and /usr/include is already there.
I've tried a C++ blank project just in case it only works for C++ files but it can't find the search path there either. Is there a setting somewhere else that's missing or wrong so I can use the standard naming scheme?
Ah! Found it. So the "Desktop Kits" for some silly reason never had a compiler selected even though during setup it automatically detected clang. Anyways, when I selected it from the Tools|Options|Build & Run|Kits tab|Desktop (default) and selected the compiler from the pulldown box code completion is working again.
My question may completely be a noob. Sorry, for that but I have been trying to compile my first Cuda code in Xcode and I'm lost where and how I could set up the IDE to invoke NVCC.
I installed the latest CUDA toolkit CUDA 6.0 and have even installed GCC 4.8 using brew. I have XCODE 5.5
When I run my code from XCODE all the directives like global are marked as unidentified.
I don't where and to change the settings to invoke NVCC. I will be really thankful, if anyone could help me with this.
Further, when I created the XCODE project, I created it as a C project. So, I placed the CUDA code in this C file, which is what is giving me the above mentioned errors. I tried to replace this .C file with a .cu file (just change the extension), which too failed badly - XCODE didn't even know what to do with the .cu files
COuld anyone please help me?
Thanks in Advance
I have given it a try. Although I have not completely succeeded I thought I'd post my progress here in hopes of helping others. The steps I took were inspired by this page.
Create a new Xcode project
Under Build Settings add a new user defined setting CC with the value /usr/local/cuda/bin/nvcc.
Add /usr/local/cuda/include to Header Search Paths under Build Settings.
Set Enable Modules (C and Objective-C) to No.
Add /usr/local/cuda/lib/libcuda.dylib to Link Binary With Libraries under Build Phases.
For any C files you create set their extension to .cu in the File Inspector, after you have done that you have to set the type of that file to C source to get syntax highlighting, by going to Editor->Syntax Coloring->C.
Problems with this setup:
- Xcode can't run the executable, at least nog if it is compiled for debugging. However you can make it copy the executable to some reasonable location and run it in the terminal.
- Whenever you try 'Build for running' sometimes Xcode magically destroys the whole project.
I'm using Eclipse Juno, trying to get the ARM toolchain working. What I have installed:
Eclipse Juno
Zylin Embedded CDT Plugin
GNU ARM Eclipse plugin
Summon-Arm-Toolchain, installed in the default ~/sat/ directory.
When I create a new C project using the Summon toolchain, the following error appears: 'Program "arm-none-eabi-gcc" not found in path.' The error location is "[Discovery Options] page in project properties." I've tried setting the Eclipse-level (Eclipse->Preferences->C/C++->Build->Environment) PATH and the project-level PATH to include this path, both relatively (~/sat) and absolutely /Users/alterscape/sat), but nothing seems to fix the problem. I've also tried manually adding the full path in the Discovery Options page. Is there a known fix? If not, is there a way to echo $PATH inside Eclipse to see what it thinks its path is?
So, here's the story: Eclipse CDT does NOT automatically re-check errors to see if they go away after you apply changes to your path. You have to manually re-build. This came as a surprise to me because I am used to my Java toolchain checking/updating errors as I make configuration changes. It isn't entirely obvious that you need to re-run Build Project to see if your changes fixed the error, but that's the path forward.
I know a question like this was already asked, but the situation is a little different, and all the answers on that problem didn't work for me.
I'm trying to compile some C code in VS2008 and it doesn't create an exe. Also, when I try to run it with f5, I get:
This application has failed to start
because MSVCR90.DLL was not found.
I did some googling and it said that this was because my c++ redistributable package wasnt installed. So I installed that, restarted everything and tried again. But alas, I still get the same error. Does anyone have any clue how to fix this?
It sounds like either a problem with your VS2008 installation, or something wrong with your DLL search path. MSVCR90.DLL is installed when you install VS2008, you shouldn't have to install any additional redistributable packages.
First I would check your PATH environment variable and make sure there is no gobbledydook in it that will break some of the entries, and if you don't find a problem there, then I would uninstall and reinstall Visual Studio.
You could also try searching for MSVCR90.DLL (and other DLLs like it), and move them to your Windows/System32 folder.
If you just want to get going now, another thing you could do is change your project to statically link to the runtime libraries, and then it wont even try to load that DLL. Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to just Multi-Threaded (or any of the options that doesn't end with DLL).
Here are some things to check for your configuration of the project- under the general tab:
.1 Configuration type - exe in your case.
.2 Use of MFC: if this is an MFC application it might be more portable if you do: Use MFC in a static library.
.3 Use of ATL - if not using atl (or not sure) say Not using ATL.
.4 Under C/C++ -> Runtime Library: Say Multi-threaded Debug (for debug version) or Multi-Threaded (for release version).
If you are getting specific linker errors that say something is already defined:
This means that you have some parts of your app (separate libs being linked to your exe) that are built with different runtime linking:
You can:
Make sure that these libraries were compiled with the same version of visual studio as your application.
Change those projects to use static runtime: C/C++ -> Code Generation -> Runtime LIbrary: /MT or MTd (same as #4 above)
If you still have some specific errors try telling the linker to ignore certain libraries: Go to Linker->Ignore Specific Library and put in the library that you want to ignore. This is most common for 'libcmt.lib' or 'libcmtd.lib'. It is important also to know that lib ending with 'd' is usually the debug version. If you are creating a release build and you are getting 'already defined in libcmtd.lib' that means that somewhere you are linking a release lib to a debug lib.
if you delete the manifest file associated with you .exe, you will get the same error.
MSVCR90.dll is not installed in system32, but in the side-by-side folder, hence the manifest is required.
I have just been bitten by this and this page got me working again.
The key is to ignore MSVCRT and MSVCR90 libraries for the debug configuration. Set your linker -> Input -> Ignore Specific Library setting to include the following:
MSVCRT
MSVCR90
it is supposedly in the http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&displaylang=en visual studio 2008 runtime library. Yes! After installing that, openoffice update works.
If you give the finished exe to someone else they will need to install the latest visual c runtime to run it. This will only work for release build AFAIK. Visual studio should install the required runtime both release and debug into your path. The project probably has an additional dependency accidently set for an incorrect version of the runtime.
See if this page helps.
Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to Multi-Threaded and then try to compile but it won't. Then change it to Multi-Threaded Debug and try to compile ,but it won't again and then you change it back to Multi-Threaded DLL and then it should compile and run.