I'm having an issue getting some code to work. Is there a way to enable headers to be included like so
#include <boost/asio.hpp>
Instead of
#include "boost/asio.hpp"
Pass the directory to be searched for that path after -I on the command line to gcc.
Related
I'm attempting to build some code using a temporary version of an include file in my local ../include/records directory. The orignal lives in /home/apps/include/records. I have my gcc command set to search ../include before /home/apps/include, but it's still picking up the original module from /home/apps/include and reporting errors. If I rename the original in /home/apps/include, then gcc picks up my local edited copy and it compiles clean. So, what's up with the include order...? This 'local include first' logic has always worked for me in the past, but this may be the first time I've used it since migrating from AIX to Linux.
Is there something beyond the order of the -I command-line options that could be overriding the requested include order?
The source module include statment is:
#include "records/novarec.h"
and the gcc command line looks like this:
$make
gcc -DLINUX64 -c -g -I. -I../include -I/home/apps/include -I/home/apps/include/em -I/home/apps/include/odbc -Wno-implicit-function-declaration -Wno-implicit-int -Wno-format-security -Wno-format-truncation -Wno-discarded-qualifiers novaget.c
The compiler complains about an undefined value that's in my local copy of novarec.h, but not in the production /home/apps/include/records/novarec.h:
novaget.c: In function ‘calcComscoreDemoV1’:
novaget.c:2651:15: error: ‘CSCD_W21_49’ undeclared (first use in this function); did you mean ‘CSCD_W25_49’?
fval = *(dm+CSCD_W21_49);
^~~~~~~~~~~
It seems like the answer is this:
My module called in 2 include files. The first one also includes the second one - and the first one lives in /home/apps/include. That seems to make gcc search there for the second include file - even though /home/apps/include is not the first include directory in my path.
When I reverse the 2 include statements in my .c file, the correct path is followed for novarec.h. i.e. when I code:
#include "spottvdemos.h" (this modules has a #include "records/novarec.h")
#include "records/novarec.h"
novarec.h gets picked up from /home/apps/include, but when I code:
#include "records/novarec.h"
#include "spottvdemos.h"
novarec gets picked up from ../include, which is what I wanted.
I am trying to compile module. I can do so by calling make, which calls
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
But I want to see preprocessed output, So I am trying to compile manually with cc -E file.c. The problem is, It cannot see header <linux/init.h>:
fatal error: linux/init.h: No such file or directory
#include <linux/init.h>
I have notice, when make is called, it first enter this dir /usr/src/linux-headers-5.0.0-38-generic, There is probably the header, but I do not know where. I have tried gcc -E -I'/usr/src/linux-headers-5.0.0-38-generic file.c, but still the same error. So how is possible to include kernel headers (which <linux/init.h> is) in user mode - that is how to include headers from another dir?
PS: as #uzsolt in comments suggested, I add include to the end of path: gcc -I /usr/src/linux-headers-5.0.0-38-generic/include. But then another header is missing - <asm/linkage.h>, and again - I have no clue in what dir this header is.
You should use find command: find /usr/src/linux-headers-5.0.0-38-generic -name MISSED_FILE.
I don't know your linux distribution but I think you should add these parameters to gcc:
-I/usr/src/linux-headers-5.0.0-38-generic/include -I/usr/src/linux-aws-headers-5.3.0-1003/arch/x86/include/
This question is related to this thread: cygwin support for C++11 in g++4.9.2
I had the same issue:
error: ‘log2’ is not a member of ‘std’
I applied the proposed patch, only to get another error.
Including cmath here
#include <cmath>
#include <iostream>
int main()
{
std::cout << "hello" << std::endl;
}
returns this error
$ g++ -std=c++11 test.cpp
In file included from test.cpp:1:0:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1107:11: error: '::lrintl' has not been declared
using ::lrintl;
^
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1129:11: error: '::rintl' has not been declared
using ::rintl;
I asked for help on the cygwin IRC channel:
[23:02] <XXX> hi, has anyone had problems with gcc 4.9.2 in cygwin? i encountered the problem discussed here : https://cygwin.com/ml/cygwin/2015-03/msg00247.html
[23:03] <XXX> yet, if i apply the patch, i get another error: /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1107:11: error: '::lrintl' has not been declared
[23:28] <YYY> long double functions are still missing on cygwin
[23:30] <XXX> so is there no way to make it work then?
[23:31] <YYY> sure, help add the missing functions to newlib/cygwin
[23:34] <XXX> i am not using any long double functions in my code -- so i assume including cmath does not work for anybody?
[23:35] <YYY> just drop the std:: instead
[23:37] <XXX> sorry, i'm not sure what you mean. remove 'std::' where ?
Sadly, the conversation ended there. I have no clue where I should 'drop std::' nor if that resolves the problem.
Can anyone help with this?
Unpatched <cmath> works fine here if I do:
auto x = log2(10);
instead of:
auto x = std::log2(10);
Perhaps that is what YYY means by 'drop std::'.
If you must use the patched <cmath>, you can either comment out the two offending lines or if you'd prefer not to modify the header any more than you already have, add some dummy definitions of rintl and lrintl before you include it. For example:
#include <stdexcept>
long double rintl(long double arg) { throw std::runtime_error("rintl not implemented"); }
long lrintl(long double arg) { throw std::runtime_error("lrintl not implemented"); }
#include <cmath>
I'm running my source file through the C preprocessor twice before compiling it, and I want to delay The #include directives until the second pass.
Intuitively, I tried this, but it doesn't work:
##include <zlib.h>
I just need a construct, that when preprocessed, will give #include mylib.
You could define a macro, like
#define INCLUDE #include
and then when you include stuff, use the macro instead.
INCLUDE <zlib.h>
In GCC's preprocessor, at least, that gives me #include <zlib.h>.
How do I at compile time undefine a compiler macro using gcc. I tried some compile args to gcc like -D but I can't get to see the "not defined" message.
Thanks
#include <iostream>
#define MYDEF
int main(){
#ifdef MYDEF
std::cout<<"defined\n";
#else
std::cout<<"not defined\n";
#endif
}
You can use the -U option with gcc, but it won't undefine a macro defined in your source code. As far as I know, there's no way to do that.
You should wrap the MYDEF definition in a preprocessor macro, the presence of which (defined on the command line) would then prevent MYDEF from being defined. A bit convoluted to be sure but you can then control the build in the way you want from the command line (or Makefile). Example:
#ifndef DONT_DEFINE_MYDEF
#define MYDEF
#endif
Then from the command line when you don't want MYDEF:
gcc -DDONT_DEFINE_MYDEF ...
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Preprocessor-Options.html#Preprocessor-Options
The -U options seemed like what you could have needed... but then again you can't override a definition contained in your source code without resorting to more preprocessor directives.
You can resort to filtering source code and give this back to gcc for compilation, like this pseudo code:
grep -v "define MYDEF" yourFile.c | gcc -o yourFile.o -xc -
Hope it helps.
The code use case is not right. As I see, you have hard coded #define in the file. If compiler initially assumes MYDEF undefined, it will define it once it start processing the file.
You should remove the line #define MYDEF. And I hope your test case will work, if you pass MYDEF to -D and -U.
Here is one possibility that doesn't completely cover your use case but which I found to be helpful in my case.
If your MYDEF were #defined in a separate header file #included from the .c file you could force the definition of the #include guard macro with the -D option (thus preventing the MYDEF #definition) then either actively #define (still with the -D option) MYDEF to something else or just leave it undefined.
It is clear that anything else defined in the header file would also be missing but this was for me a solution to forcedly undefine a macro without changing the third-party code.