I'm having issues with getting #include to actually include libraries. The compiler software doesn't want to recognize the library.
Hi Folks! I'm a somewhat new programmer.
I'm currently trying to get a library from github to work (liblightmodbus) in the microchip studio compiler.
I've followed the instructions of adding include path
Microchip Studio, Toolchain Linking
I've downloaded the .zip and unpacked it to the debug folder within the project I'm working with. Then in the solution explorer i clicked "Show all Files" and right clicked the downloaded project and "Include in Project"
Despite this once I compile the program it returns error about
lightmodbus/lightmodbus.h: No such file or directory
and flags the lines whith
#include <lightmodbus/lightmodbus.h>
What have I missed?
Your include line uses <> brackets. This informs the pre-processor to go and search the toolchain directories, as defined by Atmel/Microchip Studio.
When including files, you can choose to use either
#include "file.c"
or
#include <file.c>
This post describes the behaviour is much more detail.
In addition, unpacking the library to the debug folder is likely to be your second problem (for the reasons described in the linked post). You should instead unpack it to directory containing the rest of your source, or a sub directory of there, and include using "".
Related
I'm trying to use code that already works in another standalone project without problems.
When I bring this code into my other final project, it indicate that 'cmath' file not found.
The file with the #include is in an .hpp file (it just defines some structs for opengl stuff), so there is not a corresponding .mm file. (This is C++ code and I'm mainly an objective-c user so not sure of all the c++ stuff)
But this is for opengl stuff and works fine we not in this project.
I've tried everything to make this work.
The final project with the problem has other code that uses #include without problems.
It is almost like something is causing xcode not to recognize the path the header anymore.
I've checked its file type it is "Default C++ header"
In the final project I'm using Zxing and also using CorePlots. Not sure if they are causing any problems. Also some file are using #include not sure if that could conflict with the #incude or not. (But again the other files with #include are working fine.
Any help will be greatly appreciated...
Alternately to Jon Reid's good advice you can pick "Compile as Objective-C++" in the Build Settings. (Search for "Compile sources" in the Build Settings window.) This is a little bit wild-west but is a quick way to see if the problem is in fact your C++ source compiling as C or Objective-C
Your header file doesn't exist by itself; something must import it. Rename the importing files, changing their file types from .m to .mm.
For example, let's say your header that includes <cmath> is named foo.h. And that this in turn is used by a bar module, composed of bar.h and bar.m. So foo.h is imported in either bar.h or bar.m.
Rename bar.m to bar.mm so that it uses C++. Do the same for all .m files that depend on foo.h.
I'm trying to build a framework from libFLAC with Xcode, to use within my own Mac OS X application.
I use these FLAC sources:
http://sourceforge.net/projects/flac/files/flac-src/flac-1.2.1-src/flac-1.2.1.tar.gz/download
I only need a few of these source files but I'd rather keep everything untouched so I'm able to keep the original FLAC source if I want to I distribute the framework project with my own sources.
The flac-1.2.1.tar.gz contains these directories:
flac-1.2.1/include/
flac-1.2.1/src/libFLAC/
flac-1.2.1/src/libFLAC/include/
In order to build libFLAC, I've added the .c files from 'flac-1.2.1/src/libFLAC' into the project (as references). I also added the .h files.
The headers used in the source code are located in:
flac-1.2.1/include/FLAC/
flac-1.2.1/include/share/
flac-1.2.1/src/libFLAC/private/
For instance the sources code calls for the header are:
#include "private/bitmath.h"
#include "FLAC/assert.h"
#include "private/bitwriter.h"
#include "private/crc.h"
#include "share/alloc.h"
etc.
In Xcode, I've added these 'User Header Search Paths' to the the target Build Settings:
$(SRCROOT)/flac-1.2.1/include/
$(SRCROOT)/flac-1.2.1/src/libFLAC/include/
And of course, I've placed my flac-1.2.1 directory in the right place.
When I want to compile, the compiler doesn't find the headers file. I tried with GCC 4.2 and LLVM compiler 2.0. What am I doing wrong? Should I do something more?
I'm new into importing C sources in my otherwise all-ObjC project and I'd be happy to try whatever you throw at me. Just please avoid answering "If you can't do it, you shouldn't do it". I need to learn this and I will.
Ok I have the answer, it was really dumb. My Xcode Project folder path itself was containing a space character. The compiler doesn't like that ;)
I've run into trouble in the past when I've tried porting some C++ code written on Mac OS X to a Linux system, or trying to compile code written against an older version of gcc/g++ with a newer one:
It seems that some (older?) versions of gcc/g++ would automatically include some header files for you.
For example, code that uses printf should require #include <stdio.h>. And code that uses memcpy should require #include <string.h>. But depending on the version of gcc I'm using, it will occasionally include these for me.
It wreaks havoc when I forget to include something and then never get errors until I go to compile the code on another system. At that point it's a game of running all over the project and fixing the includes.
Has anyone else run into this? Is there a way to force gcc to autoinclude or to not autoinclude? Or, is there a way to know what it's autoincluding?
-include file
Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
Are you sure it's not other headers pulling those one's in, and on the other platforms not doing so?
When compiling on different systems, you might meet different problems and not only includes.
I would suggest investing in a continuous build system that will compile on all OS you need after each update of the code, so you are rapidly aware of any portability issue.
You can also put all common system header files inside a specific header file you will write and systematically include it in all your files.
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.
I'm using Visual Studio .NET 2003, and I'm trying to port code I've written and compiled/run successfully in Linux GCC to Windows.
I'm a newbie when using VS. I've created a new project, and added all the .c and .h files I have into the project by Project -> Add Existing Items, then chose all the .c and .h files.
I'm not familiar with how exactly compilers and linkers etc work, but is there a difference between how VS and gcc compile/link #include files? My habit of programming in Linux has been to have one main.c file, and #include all other .h or .c files that I need. Then I would only compile the main.c file. But in VS, it seems as if the #include files are not "seen" by the program, because I'm getting errors that tell me certain structures or variables were not declared, even though they are in my user-defined header files.
I'm also getting errors like DIR is an undeclared identifier. I've included , so why can't it recognize DIR?
Thank you.
Regards,
Rayne
Consider compiling your program with windows port of gcc (from Mingw32 or Cygwin) first. This will provide you with more familiar environment. If you'll still have to compile everything with VC++, you'll have more incremental process of porting.
Also, it is not evident from your post, but it seems you are trying to use dirent.h. Note that dirent.h (and corresponding libs) is not included with VC++.
One of the best ways to learn would be to start with the smallest application that you can compile on both. Expand this working and portable application step by step into the more fully featured application you desire.
Remember to add all .c/.cpp files to the 'Source Files' directory in the project as they won't be compiled otherwise.
Restrict any non-portable code (that you will need) to a single place. For example if you need to create threads, have a common create thread function used throughout (but implemented differently). Using portable libraries such as Boost can help here.