I am building an FFI crate (the sys crate part specifically), and for the most part it's a c library with a single cpp file in it. Looks like it's some sort of vendor file.
svm.cpp links to the following standard library headers
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <float.h>
#include <string.h>
#include <stdarg.h>
#include <limits.h>
#include <locale.h>
#include <thread>
#include <fstream>
#include <sstream>
#include <vector>
Strangely, this cpp file doesn't seem to link to the c++ standard libraries that it depends on, so I had to do it through the rust build system.
previously I was able to get this working by adding the following line to my build.rs
println!("cargo:rustc-flags=-l dylib=stdc++");
This works on linux using the gnu toolchain, but i'm trying to get this to work on windows using the msvc toolchain.
So the problem is that stdc++ isn't a standardized header, and isn't included in msvc. How can I link directly to each of these c++ standard library headers instead of using stdc++?
I already tried the naive approach of just trying to link to math like so
println!("cargo:rustc-flags=-l dylib=math");
which did not yield any results
Related
I have simple project where I use tiny ttmath library for C++ (big nums).
This library consists of 13 *.h files.
I have included all these files in a stupid way:
#include "ttmath\ttmath.h"
#include "ttmath\ttmathbig.h"
#include "ttmath\ttmathdec.h"
#include "ttmath\ttmathint.h"
#include "ttmath\ttmathmisc.h"
#include "ttmath\ttmathobjects.h"
#include "ttmath\ttmathparser.h"
#include "ttmath\ttmaththreads.h"
#include "ttmath\ttmathtypes.h"
#include "ttmath\ttmathuint.h"
#include "ttmath\ttmathuint_noasm.h"
#include "ttmath\ttmathuint_x86.h"
#include "ttmath\ttmathuint_x86_64.h"
What is the right way? I expect smth like this:
#include "ttmath\*.h"
but can not find...
What is the right way? I expect smth like this:
#include "ttmath\*.h"
but can not find...
That won't work because the preprocessor is not going to expand characters to match things in the way you expect wildcards to work.
My recommendation would be to create a single custom header file of your own, and place all the #include entries in there. For example, in your .c file, you can add your own header:
#include "my_header.h"
And the contents of my_header.h would be:
#include "ttmath\ttmath.h"
#include "ttmath\ttmathbig.h"
#include "ttmath\ttmathdec.h"
#include "ttmath\ttmathint.h"
#include "ttmath\ttmathmisc.h"
#include "ttmath\ttmathobjects.h"
#include "ttmath\ttmathparser.h"
#include "ttmath\ttmaththreads.h"
#include "ttmath\ttmathtypes.h"
#include "ttmath\ttmathuint.h"
#include "ttmath\ttmathuint_noasm.h"
#include "ttmath\ttmathuint_x86.h"
#include "ttmath\ttmathuint_x86_64.h"
Basically, you put everything in a single header, and include that one instead.
The preprocessor doesn't have an "include all" built into it. Neither does it accept wildcards in filenames. You'll have to manually include all of them.
A common solution is to place all the includes in a new .h file and include that one every time you need all of them.
I know that clang can compile C++ files as .mm, but CImg comes as just an individual .h file. Regardless if I change the extension to .mm or keep it as .h, it doesn't work.
First, it complains that it can't find cstdio.h. As a result, I changed all the cstd.. imports to their c counterpart as a
// Include standard C++ headers.
// This is the minimal set of required headers to make CImg-based codes compile.
#include <stdio.h> // (was #import <cstdio>)
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <math.h>
#include <time.h>
#include <exception.h>
After bringing in the x11 library, I get past the import errors into syntax errors:
namespace cimg_library_suffixed {
Error: Unknown type name 'namespace'
Is this because I changed cstdio to stdio? I'm confused..
The solution in answer form for future reference:
Compile the file the header is #included from as Obj-C++ and the header will get treated as C++ code.
I am finding some issue in the order the include headers are defined in the c / c++ files when i execute pclint.
Say the include order is ,
#include <sys/timerfd.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <fcntl.h>
#include <termios.h>
#include <errno.h>
#include <stdarg.h>
#include <string.h>
and when i execute the pclint it gives error in say , FILE is un declared etc.
Later i changed the order of include to
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <fcntl.h>
#include <termios.h>
#include <errno.h>
#include <stdarg.h>
#include <string.h>
#include <sys/timerfd.h>
i could see that many errors were gone . I am not able to figure out why is this behavior. I am using PC-lint for C/C++ (NT) Vers. 8.00w.
i have marked the include path as say, +libdir(D:\timesys\nitrogen6x\toolchain\include)
Thank You
Brijesh
Supposedly, the inclusion of header files does slightly matter, although it's rare to find such an occasion. Some include files use types, enums or something else that is only defined in another include file.
On Linux, for example, some functions require the inclusion of multiple headers. Some of the programs using those, fail if you include those headers in the wrong order.
Kinda like the final linking stage. You have to set the libs in the correct order, otherwise you may get unresolved dependencies.
If I find an example, i will post it here.
EDIT:
Found an example. Qt. Qt has the most absurdly complicated set of headers. If you include, for example, opengl.h before QtOpenGL.h, it gives you a compilation error, because inside the Qt headers it checks for the inclusion of opengl. For some reason, QtOpenGL.h must come first.
I am struggling with someone's terribly written project and I'm trying to get it compiled ASAP... (best approach would be to do this correctly but time is an issue) ... anyways, they seem to have written this with an older API, where #include <cuda.h> gave you access to the api functions.
It seems the API functions have been moved to other headers and #include <cuda.h> is no longer enough. What should I do:
Include cuda_runtime_api.h and other header files
Compile this cpp (no kernel function calls) with nvcc?
TIA
for example:
#include <cstdlib>
#include <stdio.h>
// includes CUDA Runtime
#include <cuda_runtime.h>
// maybe you need also helpers
#include <helper_cuda.h>
#include <helper_functions.h> // helper utility functions
you need to add
/usr/local/cuda-5.0/bin/nvcc
as C++ Compiler -> Tool also. works with g++ 4.4
in your .cu file you need then #include <curand_kernel.h> if you are using CURAND library
as Robert Crovella said:
You should not need to explicitly include cuda.h if you are only using
the cuda runtime API to access CUDA functionality. If you are using
the driver API, things are different.
I was looking at the doom3 code on github and I notice something unusual. Several files have only one include for a file called idlib/precompiled.h and this file have includes for several other headers like
...
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <assert.h>
#include <time.h>
#include <ctype.h>
#include <typeinfo>
#include <errno.h>
#include <math.h>
...
and to program headers
#include "../framework/BuildVersion.h"
#include "../framework/BuildDefines.h"
#include "../framework/Licensee.h"
#include "../framework/CmdSystem.h"
#include "../framework/CVarSystem.h"
I wonder if there's any good reason for that, because that's the first time I see such thing
This is called precompiled headers. The main benefit is dramatically increased compilation speed.
All the headers in precompiled.h are compiled only once per project. Without precompiled headers, each header content would be compiled multiple times: for each .cpp file it is included in.
Dependencies are best served with an include-once in the using source (pragma, guarding defines). That involves a very small overhead as you get a tree of repeated includes: including a header while including a header.
However for the standard libraries are/were sometimes not so well organized and to provide a standard base of headers this was easiest. It also reflects a kind of "module" idea, bundled headers for the basic layer.
As to local includes: it is likely to be non-object-oriented lazyiness, not expressing dependencies.