I've installed Orwell Dev-C++ 5.x and the PDCurses DevPak. However, when I try to compile the example curses application, the compiler/linker complains that it can't find curses.h. Why?
Before reading any further, keep in mind that Dev-C++ is old software, the use of which is not recommended. Rather use Code:Blocks, Visual Studio or something similar.
The issue being experienced is as a result of the project's configuration being incomplete. Make sure that the "Includes" section (Project Properties) has an entry for the directory containing curses.h ( {installDir}/include) and "Libraries" (also in "Project Properties") has an entry for {installDir}/libs, which contains curses.a.
Ideally, these directories should be set as part of the IDE configuration rather than at the project level. The process of doing so is similar to that described above.
Note that you will have to add the appropriate directories for the curses library and header to a custom makefile (-I for includes and -L for libraries) as part of the project. (Adding it to the auto-generated makefile will not work.) To do this:
Save a copy of the makefile (Makefile.win) made on first compilation (which failed) as Makefile.curses.
Edit the makefile to contain the appropriate directives (-I{installDir}/include after the other includes and -L{installDir}/libs after the other libraries).
In the project's configuration/build options, check 'Use Custom Makefile' and set it to Makefile.curses.
Related
I try to build the Airspy library but I'm having issues, it is not even including Kernel.h headers? I changed Windows SDK in project settings to no effect, and now I am seeing odd errors relating to what seems like perfectly fine syntax:
This is Win8.1 and I tried both in the settings, installing both, but still not compiling. I want to use the library to read audio from radio device but the necessary library isn't compiling (or can I include an Airspy dll and forgo the compile and build step here?)
>> it is not even including Kernel.h headers?
This library is not necessarily used in this header file. It may be used in other header files.
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib , this is the path of kernel32.lib. 1. Confirm the existence of this file. 2. check your Library Directories of VS and confirm that you fill in the path. This is a common solution to the problem of missing files.
I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.
This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.
I was wondering if anyone knew how to link a .so dynamic library (or a .a static library for that mater) in Microsoft visual studio. The following steps have not worked for either .a or .so.
I'm playing around with the vs-android plugging to develop in Android NDK using MVS and I'm trying to add a custom library, compiled as a .so, to the project.
1 - I've created a dynamic library (.so) project alongside one of the sample projects (the san-angeles project), in the same solution.
2 - I've set the .so project, let's call it "engine" as a dependency of san-angeles. The engine.so file is generated without any problems, and appears in the {SolutionFolder?}/Android/Debug folder.
3 - I've added engine.so to the linker additional includes of san-angeles and the {SolutionFolder?}/Android/Debug folder (as a full path, something like C:/projects/.../Debug) to the additional linker directories.
But when I compile san-angeles I get the error:
"arm-linux-androideabi-g++.exe: engine.so: No such file or directory"
So I'm guessing I need to do something else to add a .so/.a to a project? Maybe change the name to libengine.so or something like that? A lot of the default includes have the lib prefix, so I don't know if it's something along those lines.
Thank you for the help,
Jaime
For anybody stumbling on this problem:
Add the directory where the .so resides in Linker -> General -> Additional Library Directories. The project you are compiling must be also a Dynamic Library .so for the linker to be available. This appends the -L flag to the commandline
In the Linker -> Command Line append your .so to the Additional Options with the -l flag with quotes, e.g. -l"MyDynamicLibraryWithoutLibPrefixAndExtension". In my case I wanted to link libassimp.so -> -l"assimp"
Ok, so in my case this was solved by:
1 - Naming the generated engine.a as libengine.a
2 - Instead of, from MVS, adding engine.a to Preferences/Linker/Additional Dependencies, I added to Preferences/Linker/Command Line -l"engine"
With this, the project finally managed to find and engine.a
Hope this helps someone else. :)
I've been using VS2008/2010 for a while and I'm going to learn using Eclipse Helions for C/C++ development (mainly C).
I am abit confused about libraries and includes though.
1) How do you properly include winsock2.h for example? I've tried this:
#ifndef CONFIG_H_
#define CONFIG_H_
/* Windows-Build */
#if defined(WIN32) || defined(_WIN32)
#include <winsock2.h>
#endif
SOCKET sock;
#endif /* CONFIG_H_ */
But the compiler dosn't recognise SOCKET. Do you have to manually add the full path to winsock2 somewhere?
2) What about ws2_32.lib? Where do you include that in Eclipse? Do you have to add a path as well?
3) Having used VS mostly I'm new to makefiles. How do you include custom makefiles? Is there a good guide for starting with makefiles?
4) Is there a intellisense like in VS?
That's what I can figure out right now.
Thanks!
EDIT:
In response to the first answer:
Building target: Filesharing_core.dll
Invoking: Cygwin C Linker
gcc -L"C:\cygwin\lib\w32api" -shared -o"Filesharing_core.dll" ./src/test.o -llibws2_32.a
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibws2_32.a
collect2: ld returned 1 exit status
make: *** [Filesharing_core.dll] Error 1
First off, cygwin will usually use GCC as it's compiler. That means that there's no special windows support that you'll find in the VS compiler and editor. Be prepared to get your hands dirty.
Keep in mind that my CDT version is a bit old and I don't have Cygwin installed so some of the things below might not be accurate. Also all the compiler options that I mention are detailled in the gcc manual.
1) In your sample, nobody is defining WIN32 or _WIN32 (I don't think GCC is going to do that for you but do check). To fix that, you'll have to include the windows.h header which (I think) will take care of definning the correct macros. You could also use the -D compiler switch (configurable in your makefile or through the eclipse menus).
If you encounter missing include errors once you've fixed the defines, I believe that the windows headers are located in the C:\cygwin\usr\include\w32api folder. To add that to your include path, simply open your project properties and navigate to C/C++ General > Paths and Symbols. Add the path to the GNU C group in the Includes tabs. Depending on how you configured your project, this might have already been done for you.
If you're building with your own makefile, you should still do the previous step because it will allow the indexer to find and parse those headers. To tell the compiler about the include folder, use the -I switch.
2) I'm going to guess that ws2_32.lib is the lib file for winsock2. If this is the case, I'm not entirely sure who's responsible for building it (is there a .dll you can use instead?). You might want to check your c:\cygwin\usr\lib folder or the c:\cygwin\usr\local\lib.
If you're using a managed project (eclipse builds the makefile for you) then go to your project properties and navigate to C/C++ Build > Settings. In the Tool Settings tab, go to the libraries item in the linker section. Just add the name of the lib file and the folder in the appropriate boxes.
In your own makefile you'll want to use the -l compiler switch to specify a library and the -L compiler switch to specify a search path.
3) A good place to get started with makefiles would be the GNU make manual.
One detail about running a Makefile on Windows: make sure to use the shell provided by Cygwin or MinGW. Otherwise, commands like rm won't be defined and it'll make your life very difficult.
You might also want to consider CMake. It's easier to use and scales better to larger projects.
To use a hand-made makefile in your project, just create an new Makefile project and dump your Makefile file in the root of your project folder. That's it.
4) Yes there is but it's not called intellisense. Just hit CTRL+Space anywhere in your source code to bring it up.
Other fun tools can be found in the right-click menu. My personal favorites include CTRL+SHIFT+R to find and open a file, CTRL+SHIFT+T to find and open a type\variable\function\define and CTRL+O to find and goto a type\variable\function\define within the opened file.
The indexer can go a little crazy sometimes (mostly when parsing C++ code). You can modify its behaviour by going in the Windows > Preferences menu at the top and navigating to the C/C++ > Indexer item.
I hope this helps.
I'm sure this question has been asked many times, but I can't figure this out. Bear with me.
So when you download a library, you get a bunch of .c and .h files, plus a lot of other stuff. Now say you want to write a program using this library.
I copy all the .h files into my project directory. It just doesn't compile.
Great, so then I get the library as a bunch of .dll's, and i copy the dlls into my project directory. Still doesn't compile.
How does this work?
What do you do, like right after creating the folder for your project? What parts of the library package do you copy/paste into the folder? How do you make it so that it can compile? Go through the steps with me please.
Where to put the .h files?
Where to put the .dll files?
How to compile?
Thanks.
(the library I'm trying to get working is libpng, I'm in windows with MinGW, and i'm looking to compile from command-line like usual.)
(from what i gather, you put the .h files in directory A and the .dll files in directory B and you can use -l and -L compiler options to tell the compiler where to find them, is this correct?)
Here's a brief guide to what happens when you compile and build a basic C project:
The first stage compiles all your source files - this takes the source files you've written and translates them into what are called object files. At this stage the compiler needs to know the declaration of all functions you use in your code, even in external libraries, so you need to use #include to include the header files of whatever libraries you use. This also means that you need to tell the compiler the location of those header files. With GCC you can use the -I command line to feed in directories to be searched for header files.
The next stage is to link all the object files together into one executable. At this stage the linker needs to resolve the calls to external libraries. This means you need the library in object form. Most libraries will give you instructions on how to generate this or might supply it ready built. Under Linux the library file is often a .a or .so file, though it might just be a .o. Again you can feed the location of the library's object file to GCC with the -L option.
Thus your command line would look like this:
gcc myProg.c -I/path/to/libpng/include -L/path/to/libpng/lib -lpng -o myProg.exe
(Note that when using the -l command line GCC automatically adds lib to the start of the library, so -lpng causes libpng.a to be linked in.)
Hope that helps.
Doing it under windows (supposing you user Visual Studio)
After unpacking add the library include directories to your projects' settings (Project -> Properties -> C/C++ -> Additional Include Directories)
Do the same thing for the Libraries Directory (Project -> Properties -> Linker -> Additional Library Directories)
Specify the name of the library in your Linker Input: Project -> Properties -> Linker -> Input -> Additional Dependencies
After this hopefully should compile.
I don't recommend adding the directories above to the Global settings in Visual Studio (Tools -> Options -> Project and Solutions) since it will create and environment where something compiles on your computer and does NOT compile on another one.
Now, the hard way, doing it for a Makefile based build system:
Unpack your stuff
Specify the include directory under the -I g++ flag
Specify the Library directory under the -L g++ flag
Specify the libraries to use like: -llibrary name (for example: -lxml2 for libxml2.so)
Specify the static libraries like: library name.a
at the end you should have a command which is ugly and looks like:
g++ -I/work/my_library/include -L/work/my_library/lib -lmylib my_static.a -o appname_exe MYFILE.CPP
(the line above is not really tested just a general idea)
I recommend go, grab a template makefile from somewhere and add in all your stuff.
You must link against a .lib or something equivalent i.e. add the ".lib" to the libraries read by the linker. At least that's how it works under Linux... haven't done Windows so a long while.
The ".lib" contains symbols to data/functions inside the .dll shared library.
It depends on the library. For examples, some libraries contain precompiled binaries (e.g. dlls) and others you need to compile them yourself. You'd better see the library's documentation.
Basically, to compile you should:
(1) have the library's include (.h) file location in the compiler's include path,
(2) have the library stubs (.lib) location in the linker's library path, and have the linker reference the relevant library file.
In order to run the program you need to have the shared libraries (dlls) where the loader can see them, for example in your system32 directory.
There are two kinds of libraries: static and dynamic (or shared.)
Static libraries come in an object format and you link them directly into your application.
Shared or dynamic libraries reside in a seperate file (.dll or .so) which must be present at the time your application is run. They also come with object files you must link against your application, but in this case they contain nothing more than stubs that find and call the runtime binary (the .dll or the .so).
In either case, you must have some header files containing the signatures (declarations) of the library functions, else your code won't compile.
Some 'libraries' are header-only and you need do nothing more than include them. Some consist of header and source files. In that case you should compile and link the sources against your application just as you would do with a source file you wrote.
When you compile, assuming you have the libs and the headers in the same folder as the sources you are compiling, you need to add to your compile line -L . -I . -lpng. -L tells the linker where to look for the library, -I tells the compiler where to look for the headers and -lpng tells the linker to link with the png library.
[Edit]
Normal projects would have some sort of hierarchy where the headers are in an /include folder and the 3rd party libs are in a /libs folder. In this case, you'd put -I ./include and -L ./libs instead of -I . and -L.
[Edit2] Most projects make use of makefile in order to compile from the command line. You can only compile manually for a small number of files, it gets quite hectic after that
Also,
you may want to look over Dynamic Loading support in various languages and on various
platforms.
This support is very handy in cases when you want to use a library optionally and you don't want your program to fail in case that library is not available.