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.
Related
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.
Okay here goes, I'm completely new at this, started learning the terminal just about 2 days ago. I'm slowly but surely getting the hang of it, now I'm stuck on this and I've been trying to fix it for a good hour. It's a rather simple question as I am a newby.
I have a C file in my desktop and a Header file in a folder in my desktop. I'm including that header in my C file. I have to link them (currently doing a tutorial, it tells me to link, but doesn't show me how).
You have a couple of options. First, you will need to install the software development environment - it's called Xcode. I think you can get it for free on the AppStore, if not Google it.
Then you need to decide if you want to develop and compile graphically in the Xcode Integrated Development Environment. If you do, start Xcode and create a new project and open your C file and change the "include path" to match the location of your header file. Then click "Build" and "Run"
If you want to do things at the commandline, you'll need to install "Xcode Command Line Tools" - Google it. That will give you a compiler. Then you can compile. I'm not certain which compiler you will get - it could be "llvm" or "gcc" or something else, but the command you are looking for will be something like:
gcc -o prog -I /path/to/HeaderFileFolder yoursourcecode.c
which will give you a program called "prog" that you can run by typing
./prog
You are likely confusing two different concepts. The "link" mentioned in the tutorial is probably talking about turning the compiled objects into a single executable. See http://www.cprogramming.com/compilingandlinking.html for an explanation of what linking means in this context.
What you've provided examples of doing is file system linking, which is totally unrelated.
Providing more details on the tutorial could help refine this answer.
I'm having a strange problem with include files and an apparent disconnect between Eclipse's build process and its error reporting. I'll give detailed steps to reproducing this problem, so we can narrow the causes down as quickly as possible.
Eclipse 3.7.1 (Indigo SR1) for C/C++ Linux Developers, Ubuntu 10.10 64-bits
It all started when I imported an existing project that "makes" just fine on its own: I thought Eclipse would help considerably in navigating the files and figuring out what does what. However, some of the #included system headers seemed not to be having the correct effect in Eclipse's view. This was very puzzling, and in the course of investigating this, I managed to recreate the problem in a tiny sand box.
Step one: Create a new C project (File: New: C Project) using the Hello World ANSI C Project sample. The parameters are Executable: Hello World ANSI C Project/Linux GCC, the remaining Empty projects set to Linux GCC, and GNU Autotools set to Hello World ANSI C Autotools Project. Call it "hello". Be sure to generate the makefile automatically (Advanced Settings, I believe it is the default).
Step two: Adjust the include path. Using Project: Properties: C/C++ General: Paths and Symbols: Includes: GNU C, set the search path to /usr/local/include, /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include, /usr/include. The second path depends on the exact version of gcc you have installed. This doesn't matter too much, as long as the build path includes at least /usr/include.
Now if you open hello.c, it looks very simple, and Eclipse is quite happy except for return EXIT_SUCCESS;, which cannot resolve EXIT_SUCCESS. Replace EXIT_SUCCESS with a zero (0) and Eclipse gives the all-clear. Select Project: Build Project to generate the executable.
Open a command-line window and drill down to your Eclipse workspace folder's hello/Debug subfolder. Once there, you can run the executable with the line ./hello.
Now the fun begins. Modify hello.c to read in its latter part:
#include <fcntl.h>
int main(void) {
printf("Hello World!\n");
int zz = SPLICE_F_MOVE;
printf("zz (SPLICE_F_MOVE) is '%d'\n", zz);
printf("Bye World!\n");
return 0;
}
You'll get an error on the int zz... line: "Symbol 'SPLICE_F_MOVE' could not be resolved". If you Build the project, you'll get a similar error in the console view: "error: 'SPLICE_F_MOVE' undeclared".
Now if you change the preamble to:
#define _GNU_SOURCE
#include <fcntl.h>
You still get the error on the int zz line (in the editor), but the project will Build correctly! You can confirm this by running the binary in the command-line window you opened earlier. This is really odd since examination of /usr/include/fcntl.h will show that it #includes <bits/fcntl.h>, and that latter header #defines SPLICE_F_MOVE (and a bunch of others) in a block guarded by #ifdef __USE_GNU (__USE_GNU gets #defined if _GNU_SOURCE is #defined). Why on Earth isn't our #define _GNU_SOURCE properly propagated in the workspace perspective?
So this is my problem in a nutshell: why is it the editor (and all of Eclipse CDT) reports an error (apparently by refusing to process correctly an include), but that the underlying build succeeds?
I had similar problems working with GNU and non-GNU compliant toolchains for cross-compiling various microcontrollers. CDT reports lots of errors, but the actual build works perfectly, even when all the header includes are correctly located in the project settings.
The problem is in how CDT operates as distinct from your make system build. CDT is a standalone lexer, parser, and preprocessor and doesn't make use of the toolchain you're using to do the build. This normally would work fine once you set the project settings to match those generated as command-line arguments to your build tools, but many toolchains frequently include hidden implicit defines as part of their compiler/preprocessor itself. The documentation for the implict/hidden defines is usually sketchy and incomplete in my experience, making it nearly impossible to determine which defines are set for a given toolchain (sometimes even dependent on build options) and what they mean. While it may look like you have all the correct defines set to reach the one you're having a problem with, I usually find (especially with GNU) that there are some you're missing that prevent the switch from being processed the way you expected.
When I debug something like this, I first make sure any headers in my project directory are found first if they have names matching those in other directories, then I slowly start moving headers from the standard include folder to my project folder. CDT doesn't do a very good job of indicating which possible versions of a header file it's parsing first, and it frequently pulls system environment settings when you least expect it, but it does look in your project folder for headers first (if you haven't set the system headers path in your project settings to take precedence). By moving the system headers from the location you're looking at to your project directory, you know for sure exactly which header file is being parsed by CDT. Furthermore, if you rebuild your index after doing the move, then open the file in Eclipse, CDT will indicate what switches it believes are enabled or disabled by greying-out or folding the branches not enabled in the header. Following this process has solved this exact problem for me every time, revealing when I had paths to multiple copies of the same header, accidentally duplicated headers, had defines or includes under unexpected switches, etc.
I have the same issue, but didn't even do anything that complicated to produce it--I just made a hello world project of the type you describe and get the same error. Note that, however, in my case, it may be due to a borked install of cygwin--for instance, I had other errors concerning failing to include the .h files, and a complete deletion/reinstall of cygwin removed those errors but the 'Symbol ... Could not be resolved' error remains.
I then decided to make a second such project, and they both report such an error in the 'problems' view, but only one of the projects actually shows the error underlined etc. in the editor (!)
Maybe this issue comes from Ijndigo itself. Did you tried the same with the latest Indigo SR2? I opened a number of bugs for Indigo and its SR1 in eclipse bugzilla.
I have NetBeans 6.9 installed and working fine on Ubuntu Linux 11.10. My goal is to set compiler options like -Wall and -std=c99 to be used by default. Currently, I have to right click on my project -> Properties -> C Compiler -> Warning Level to "More Warnings" and add -std=c99 to Additional Options. This is obviously a pain when creating many projects, and I'm sure there is a way to make all of this the default.
I found this thread which relates closely to my question. However, the only answer involves installing Code::Blocks and MSYS 1.0.11, which doesn't make much sense to me. I don't see how installing another IDE will help me, and MSYS seems unnecessary, as I am already using Linux.
I have tried every reasonable search term I can imagine, and am very surprised how little info I have turned up. It seems like most everyone who uses NetBeans should have to change this type of thing at some point. Terms I'm searching for: 'NetBeans -std=c99 default', 'NetBeans set default compile options', 'how to make NetBeans use c99 by default' and 'Code::Blocks settings into NetBeans'.
Here are some different things that you can do:
Copy and share the configuration files between projects, so you won't have to set every setting.
Create a default project, and configure however you like it. When you want to create a new project, just copy the default project and rename it to something else.
Modify your toolchain properties.
For details, see here:
NetBeans settings for GCC
You can create a Project Template Module. I was aware this is possible but didn't try it before, and this link is explaining how to do it;
https://blogs.oracle.com/seapegasus/entry/tip_create_your_own_project
(First you need NetBeans with platform SDK, not just C/C++ Bundle.)
I followed steps;
Open/Create your project with settings you want to use.
Create a NetBeans module project, choose a Code Base Name, i gave my.templates.ctemplate1
Add "Module Development > Project Template" to the module project. Choose your C project in "Select Project" step.
At next step select the Category as C/C++ and give a name for template i used MyCTemplate1.
Right click on module project and select "Create NBM", it will create my-templates-ctemplate1.nbm in the build folder of the module project.
Tools > Plugins > Downloaded , click "Add Plugin" and point to the nbm file in the build folder. Select install, it will give warnings because it's not signed.
When you want to create a new C/C++ project you will see your template in the wizard which will have all the settings as your first C project has.
Enjoy other possibilities; files, folders in original project will be there.
Have you tried editing your netbeans.conf file (for me, it's in /usr/local/netbeans-7.0.1/etc/netbeans.conf) and adding the options you need to the netbeans_default_options line? From looking at my version of the file, you might need to prepend -J to the switches (hence -Wall would become -J-Wall.)
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