As the title stated, I want my compiler to fail when I include some header files; for example, <cmath>
Is that possible with just compiler flags? Or do I have to actually delete those headers?
#include <cmath> has nothing to do with any library, and everything to do with a header file. Assuming that you really do mean that you want compilation to fail if you include a particular header file, you should be able to leverage GCC's support for specifying include directories through environment variables.
To do so, create or edit an appropriate environment file. If you are using GNU bash on Debian, for example, you can create a file /etc/profile.d/gcc-include-dirs. Everything readable in /etc/profile.d is sourced when a shell is launched, so it will apply to all shells started after that point. (To be absolutely certain, you may want to log out and back in once, then issue env | grep INCLUDE to confirm.) Create such a file with your favorite editor and add the following to it:
export C_INCLUDE_PATH=/usr/local/include/fail:${C_INCLUDE_PATH}
export CPLUS_INCLUDE_PATH=/usr/local/include/fail:${CPLUS_INCLUDE_PATH}
Make sure the file is readable by everyone (chmod 644 /etc/profile/gcc-include-dirs) and that it is owned by root (chown root:root /etc/profile/gcc-include-dirs).
You can also put the file elsewhere and simply source it when needed, if you only need this behavior at specific times. In that case, logging out from the shell in question and logging back in will restore GCC's normal behavior (you don't need to log out from the entire session, just that particular shell instance). Starting a subshell and sourcing the file from within that subshell will also work nicely in that case; just exit when you are done.
Then create a file /usr/local/include/fail/cmath with the following content:
#error "Failing because you included 'cmath'"
Make sure that file too is readable by everyone and owned by root. #error and its evil twin #warning emit a fatal error and a compilation warning, respectively, so whenever this file gets included, GCC will encounter a #error preprocessor directive resulting in the emission of a fatal error which causes the compilation to fail.
If you want to override this behavior for a single compilation, simply use gcc's -I parameter to specify the path to the directory where the real math.h lives. Since -I takes precedence over $C_INCLUDE_PATH and $CPLUS_INCLUDE_PATH this means that you then include the C library's version. For example, cc -o mathprogram -I/usr/include mathprogram.c will use the math.h in /usr/include when you #include <math.h> regardless of what might be in /usr/local/include/fail, because it looks first in /usr/include.
Since this only affects compilation (and only compilation started through a shell), everything that is already on your system will be completely unaffected (unless they have some weird dependencies to those two environment variables).
For c* headers, you may need to also create the corresponding *.h header with content identical to the c* header. This is because e.g. cmath might simply map to math.h (the name of the same header in C). Simply make another file just like the one above, but complain about math.h instead. (GCC doesn't care, but it makes diagnostics easier.) You may also need to put files in other places (I'm not sure exactly what include directory structure GCC wants for C++ headers); in that case, find / -name cmath (or something similar) will give you an idea of the structure you need to replicate under /usr/local/include/fail.
Do note that this will not stop people simply copying the relevant parts of the header file into their own source code; there is nothing magical about the header files from the compiler's point of view. Depending on exactly what you are trying to protect against, this may be an issue.
What about simply using a pre-processor symbol to omit the library header(s)?
Compiling with the gcc option -DDONT_WANT_LIBS will fail due to the missing library declarations in the library header file.
#ifndef DONT_WANT_LIBS
#include<specific_library_header.h>
#endif
...
...
Related
I have a module module1 in a file called mymodule.f90. What should I do in order to make module1 usable like fortran intrinsic module?, i.e. it need only be called in a use statement (use module1) in any programs, subroutines, or functions that use it but I don't need to link /path/to/mymodule/ when compiling those procedures.
I use gfortran, but possibly in the future I will also have to use the Intel fortran compiler.
So maybe I'm misunderstanding you, but you want to use a module without having to tell the compiler where to find the .mod file (that contains the interface definitions for whatever module1 exports), or the linker where the object code can be found?
If so, for GFortran the solution is to download the GCC source code, add your own module as an intrinsic module, and then build your own custom version of GFortran. As a word of warning, unless you're familiar with the GFortran/GCC internals, while this isn't rocket science, it isn't trivial either.
For Intel Fortran, where you presumably don't have access to the source code of the compiler, I suppose you're out of luck.
My suggestion is to forget about this, and instead tell the compiler/linker where your .mod files and object files can be found. There are tools like make, cmake etc. that can help you automate this.
When you compile mymodule.f90 you will obtain an object file (mymodule.o) and a module file (mymodule1.mod). The compiler needs to have access to the module file when it compiles other files that use mymodule1, and the linker needs to have access to the object file when it generates the binary.
You don't need to specify the location of intrinsic modules because they are built in into the compiler. That will not be the case with your modules: you may be able to set up your environment in a way that the locations of your files allow the compiler to find the files without explicitly specifying their paths in compilation or linking commands, but the fact that you don't see it does not mean it's not happening.
For the Intel compiler, the answer is given by https://software.intel.com/en-us/node/694273 :
Directories are searched for .mod files in this order:
1 Directory of the source file that contains the USE statement.
2 Directories specified by the module path compiler option.
3 Current working directory.
4 Directories specified by the -Idir (Linux* and OS X*) or /include (Windows*) option.
5 Directories specified with the CPATH or INCLUDE environment variable.
6 Standard system directories.
For gfortran I have not found such a clear ordered list, but relevant information can be found in
https://gcc.gnu.org/onlinedocs/gfortran/Directory-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
It should be clear to you that a compiler won't be able to understand module files created by other compilers, or even by different enough versions of the same compiler. Therefore, you would need a copy of your "always available" module for each compiler you use, and if you are using multiple versions of a compiler you may need up to one per version - each of them in a different directory to avoid errors.
As you can see, this is not particularly practical, and it is indeed far from common practice. It is usually easier and more clear to the user to specify the path to the relevant module file in the compilation command. This is quite easy to set up if you compile your code using tools such as make.
Finally, remember that, if you make such arrangements for module files, you will also need to make arrangements for the corresponding object files at the linking stage.
Trying to do this and stumbled upon the -I option here: $ g++ -o version version.cpp -I/usr/local/qt4/include/QtCore -I/usr/local/qt4/include -L/usr/local/qt4/lib -lQtCore
I can't find any information about it
If you're looking for what -I does:
-I[/path/to/header-files]
Add search path to header files (.h) or (.hpp).
From https://caiorss.github.io/C-Cpp-Notes/compiler-flags-options.html
This pretty much just means that any #include statements you make to an external library (in your case qt) have to be referenced so that g++ knows where to look.
if my understanding is correct, question is about -i, not -L, I hope this helps:
-Idir Append directory dir to the list of directories searched for include files.
on this link
http://www.cs.virginia.edu/helpnet/Software_Development/compilers/g.html
g++ - GNU project C++ Compiler (v2 preliminary)
g++ [option | filename] ...
Capabilities
The C and C++ compilers are integrated. Both process input files through one or more of four stages: preprocessing, compilation, assembly, and linking.
C++ source files use one of the suffixes `.C', `.cc', or `.cxx'.
Options
There are many command-line options, including options to control details of optimization, warnings, and code generation, which are common to both gcc and g++. For full information on all options, see gcc(1).
Options must be separate: -dr' is quite different from- d -r '.
-c Compile or assemble the source files, but do not link. The compiler output is an object file corresponding to each source file.
-Dmacro Define macro macro with the string `1' as its definition.
-Dmacro=defn Define macro as defn
-E Stop after the preprocessing stage; do not run the compiler proper. The output is preprocessed source code, which is sent to the standard output.
- g Produce debugging information in the operating system's native format (for DBX or SDB or DWARF). GDB also can work with this debugging information. On most systems that use DBX format, `-g' enables use of extra debugging information that only GDB can use.
Unlike most other C compilers, GNU CC allows you to use ` -g' with `-O'. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
-Idir Append directory dir to the list of directories searched for include files.
-llibrary Use the library named library when linking. (C++ programs often require `-lg++' for successful linking.)
-O Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.
Without `-O', the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.
Without `-O', only variables declared register are allocated in registers. The resulting compiled code is a little worse than produced by PCC without `-O'.
With `-O', the compiler tries to reduce code size and execution time.
-o file Place output in file file.
I'm wanting to setup my CMakeLists.txt file so that it can generate the .clang_complete file required by the vim plugin clang_complete.
Ordinarily, you would do this by passing a parameter to the python script it supplies with the compiler and all of the parameters for compilation. Note that I am omitting the actual directory cc_args.py is in to save on space.
cc_args.py gcc test.c -o test -I~/IncludeDirs/
You can also do this during the make phase...
make CC='cc_args.py gcc' CXX='cc_args.py g++'
However, I am unsure of how to (if it is possible to) set this up within a CMakeLists.txt file. It's really annoying to have to type this in every time I want to setup clang_complete. The reason why I want to do it this way, is because I have multiple projects that I use a custom script to build the CMakeLists.txt file, so having to write a script for each one or manually place a generic one is a step I'd like to avoid.
I've tried a couple of things that have so far have come up with errors.
I've tried setting CMAKE_CC_COMPILER and CMAKE_CXX_COMPILER to lines similar to the first i.e. "cc_args.py g++". The errors that come up here say that It can't find the compiler (which is understandable).
The next thing I tried was setting the Compiler variables just to the cc_args.py and adding a flag for the actual compiler: suffice to say, that failed horribly. CMake said that it couldn't compile a test program (considering the script isn't a compiler, and the tests don't use the flags I set, I'm not surprised at this).
So without writing any other external scripts that require moving around, is there anyone that can think of a way that can do this?
The solution is to set the CXX environment variable before executing cmake. Something like that:
CXX="$HOME/.vim/bin/cc_args.py clang++" cmake ..
make
See http://www.guyrutenberg.com/2013/01/29/vim-creating-clang_complete-using-cmake/ for more details.
I know you said "without writing any other external scripts," but it seems like you just need a one-liner:
exec cc_args.py g++
And then set that file as your CMAKE_CXX_COMPILER. You could even use CMake's file() function to write the one-liner at build time if you don't want to have to distribute it.
There are struct definitions in the .h file that my library creates after I build it.. but I cannot find these in the corresponding .h.in. Can somebody tell me how all this works and where it gets the extra info from?
To be specific: I am building pth, the userspace threading library. It has pth_p.h.in, which doesn't contain the struct definition I am looking for, yet when I build the library, a pth_p.h appears and it has the definition I need.
In fact, I have searched every single file in the library before it is built and cannot find where it is generating the struct definition.
Pth uses GNU Autoconf, Automake, and Libtool. By running ./configure you'll be running a shell script which eventually runs m4 to detect the presence of a whole bunch of different system attributes and make changes to a number of files.
It looks like it boils down to ./configure generating Makefile from Makefile.in and then running something via make that triggers the shtool subcommand scpp:
pth_p.h: $(S)pth_p.h.in
$(SHTOOL) scpp -o pth_p.h -t $(S)pth_p.h.in -Dcpp -Cintern -M '==#==' $(HSRCS)
Obscure link, but here's an shtool-scpp manpage, which describes it as:
This command is an additional ANSI C
source file pre-processor for sharing
cpp(1) code segments, internal
variables and internal functions. The
intention for this comes from writing
libraries in ANSI C. Here a common
shared internal header file is usually
used for sharing information between
the library source files.
The operation is to parse special
constructs in files, generate a few
things out of these constructs and
insert them at position mark in tfile
by writing the output to ofile.
Additionally the files are never
touched or modified. Instead the
constructs are removed later by the
cpp(1) phase of the build process. The
only prerequisite is that every file
has a ``"#include ""ofile"""'' at the
top.
.h.in is probably processed within a configure (generated from configure.ac) script, look out for
AC_CONFIG_FILES([thatfile.h])
It replaces variables of the form #VAR# in the .in file with their values.
Edit: Just noticed if I'm right you should retag your question
The (hypothetical for now) situation is the user of my system is going to be given a chunk of C code and needs my system to compile and run it in a chroot sandbox that is generated on the fly and I want to require the fewest files in the box as possible. I'm only willing to play with compiler and linker settings (e.g. static link everything I can expect to be able to find) and make some moderate restriction on what the code can expect use (e.g. they can't use arbitrary libs).
The question is how simple can I get the sandbox. Clearly I need the executable, but what about an ELF loader and a .so for the system calls? Can I dump either of them and is there something else I'll need?
You don't need anything except the executable to run a statically-linked hello world. You will, of course, need a lot more to compile it.
You can test this fairly easily, I did so with the following trivial C code:
#include <stdio.h>
int main() {
puts("Hello, world\n");
return 0;
}
compile it with gcc -static. Then make a new directory (I called it "chroot-dir"), move the output ("hello") into it. So the only file in the chroot is now the executable. Then run chroot chroot-dir ./hello, and you'll get Hello, world.
Note that there are some things that can not be compiled statically. For example, if your program does authentication (through PAM), PAM modules are always loaded dynamically. Also note that various files in /etc are needed for certain calls; any of the getpw* and getgr* functions, the domain name resolution functions, etc. will require nsswitch.conf (and some shared objects, and maybe more config files, and sometimes even more executables, depending on the lookup methods configured.) /etc/hosts, /etc/services, and /etc/protocols will probably be quite useful for any networking.
One easy way to figure out what files a program uses is to run it under strace. You must trust the program first, of course.
no need for any ELF loader. to check what dynamic libraries you need do ldd <executable>. If you manage to static compile everything, it won't need any .so. Beyond that, it's only about the data and directory structure your program might need.
But all this is only if you use the /usr/bin/chroot command; if you make your program call int chroot(const char *path); itself after making sure all dynamic libraries are loaded, they you won't need anything on the directory sandbox. not even the executable itself.
edit: A different idea: use TCC (or rather, libtcc to compile, link, load and run the given C chunk. run the whole process inside an 'outer' chroot jail, dropping to an 'inner' (empty) one just before execution. (of course, execute in a fork(), or you won't be able to break out of the 'inner' jail to the 'outer' one). You might also take advantage of libtcc's bound's checked execution.