I need to compiler source code that contains includes like this:
#include <tr1/unordered_map>
However my compiler (based on GCC 4.6) does not have the tr1 directory. I need to somehow tell the compiler to map <tr1/unordered_map> to <unordered_map without modifying source code of file system?
when you build your code, provide include directory as an argument.
-I. - For current directory as an include directory
-I tr1 - tr1 as an include directory.
-I /yourpath/ - To put any directory as include directory
Gcc headers <unordered_map> and <tr1/unordered_map> are different. One requires C++11 support turned on, the other does not. Substituting one for the other may or may not work.
Probably the easiest solution to your problem is to use the tr1 implementation from Boost.
A bit hacky: Go to the include directory containing unordered_map and:
ln -s . tr1
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'm experimenting a bit with building DLLs on windows using MINGW.
A very good summary (in my opinion) can be found at:
https://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/
There is even a basic project which can be used for the purpose of this discussion:
https://github.com/TransmissionZero/MinGW-DLL-Example/releases/tag/rel%2Fv1.1
Note there is a cosmetic mistake in this project which will make it fail out of the box: the Makefile does not create an "obj" directory - Either adjust the Makefile or create it manually.
So here is the real question.
How to change the Windows DLL name so it differs from the actual DLL file name ??
Essentially I'm trying to achieve on Windows, the effect which is very well described here on Linux:
https://www.man7.org/conf/lca2006/shared_libraries/slide4b.html
Initially I tried changing "InternalName" and ""OriginalFilename" in the resource file used to create the DLL but that does not work.
In a second step, I tried adding "-Wl,-soname,SoName.dll" on the command that performs the final link, to change the Windows DLL name.
However, that does not seem to have the expected effect (I'm using MingW 7.3.0, x86_64-posix-seh-rev0).
Two things makes me say that:
1/ The test executable still works (I would expect it to fail, because it tries to locate SoName.dll but can't find it).
2/ "pexports.exe AddLib.dll" produces the output below, where the library name hasn't changed:
LIBRARY "AddLib.dll"
EXPORTS
Add
bar DATA
foo DATA
Am I doing anything wrong ? Are my expectations wrong perhaps ?
Thanks for your help !
David
First of all, I would like to say it's important to use either a .def file for specifying the exported symbols or use __declspec(dllexport) / __declspec(dllimport), but never mix these two methods. There is also another method using the -Wl,--export-all-symbols linker flag, but I think that's ugly and should only be used when quick and dirty is what you want.
It is possible to tell MinGW to use a DLL filename that does not match the library name. In the link step use -o to specify the DLL and use -Wl,--out-implib, to specify the library file.
Let me illustrate by showing how to build chebyshev as a both static and shared library. Its sources consist of only only 2 files: chebyshev.h and chebyshev.c.
Compile
gcc -c -o chebyshev.o chebyshev.c -I. -O3
Create static library
ar cr libchebyshev.a chebyshev.o
Create a .def file (as it wasn't supplied and __declspec(dllexport) / __declspec(dllimport) wasn't used either). Note that this file doesn't contain a line with LIBRARY allowing the linker to specify the DLL filename later.
There are several ways to do this if the .def file wasn't supplied by the project:
3.1. Get the symbols from the .h file(s). This may be hard as sometimes you need to distinguish for example between type definitions (like typedef, enum, struct) and actual functions and variables that need to be exported;
echo "EXPORTS" > chebyshev.def
sed -n -e "s/^.* \**\(chebyshev_.*\) *(.*$/\1/p" chebyshev.h >> chebyshev.def
3.2. Use nm to list symbols in the library file and filter out the type of symbols you need.
echo "EXPORTS" > chebyshev.def
nm -f posix --defined-only -p libchebyshev.a | sed -n -e "s/^_*\([^ ]*\) T .*$/\1/p" >> chebyshev.def
Link the static library into the shared library.
gcc -shared -s -mwindows -def chebyshev.def -o chebyshev-0.dll -Wl,--out-implib,libchebyshev.dll.a libchebyshev.a
If you have a project that uses __declspec(dllexport) / __declspec(dllimport) things are a lot easier. And you can even have the link step generate a .def file using the -Wl,--output-def, linker flag like this:
gcc -shared -s -mwindows -o myproject.dll -Wl,--out-implib,myproject.dll.a -Wl,--output-def,myproject.def myproject.o
This answer is based on my experiences with C. For C++ you really should use __declspec(dllexport) / __declspec(dllimport).
I believe I have found one mechanism to achieve on Windows, the effect described for Linux in https://www.man7.org/conf/lca2006/shared_libraries/slide4b.html
This involves dll_tool
In the example Makefile there was originally this line:
gcc -o AddLib.dll obj/add.o obj/resource.o -shared -s -Wl,--subsystem,windows,--out-implib,libaddlib.a
I simply replaced it with the 2 lines below instead:
dlltool -e obj/exports.o --dllname soname.dll -l libAddLib.a obj/resource.o obj/add.o
gcc -o AddLib.dll obj/resource.o obj/add.o obj/exports.o -shared -s -Wl,--subsystem,windows
Really, the key seems to be the creation with dlltool of an exports file in conjunction with dllname. This exports file is linked with the object files that make up the body of the DLL and it handles the interface between the DLL and the outside world. Note that dlltool also creates the "import library" at the same time
Now I get the expected effect, and I can see that the "Internal DLL name" (not sure what the correct terminology is) has changed:
First evidence:
>> dlltool.exe -I libAddLib.a
soname.dll
Second evidence:
>> pexports.exe AddLib.dll
LIBRARY "soname.dll"
EXPORTS
Add
bar DATA
foo DATA
Third evidence:
>> AddTest.exe
Error: the code execution cannot proceed because soname.dll was not found.
Although the desired effect is achieved, this still seems to be some sort of workaround. My understanding (but I could well be wrong) is that the gcc option "-Wl,-soname" should achieve exactly the same thing. At least it does on Linux, but is this broken on Windows perhaps ??
I've got a working project that I need to take parts from it without changing it's code and just write new main() for it.
My directory structure:
[main_dir]/[main.cpp]
[main_dir]/[dir1]/[child1]/file1.h
[main_dir]/[dir2]/[child2]/file2.h
in main.cpp I have: include "dir1/child1/file1.h"
In file1.h I have: include "dir2/child2/file2.h"
I'm compiling:
g++ main main.cpp
I'm getting "dir2/child2/file2.h" no such file or directory.
I can't change file1 to do: include "../../dir2/child2/file2.h"
Somehow in the original project something in the makefile to search for all include path relative to the [main_dir] so the include from file1.h can be found.
What should I add to the makefile in order to do it as well?
When using double-quotes to include a header file, as in
#include "dir2/child2/file2.h"
then the compiler will use the directory of the current file to search for the header file.
If you have it in your file1.h then the compiler will look for the header file [main_dir]/dir1/child1/dir2/child2/file2.h. Which isn't correct.
You can solve it by telling the compiler to add [main_dir] to the list of standard include search paths. This is done with the -I (upper-case i) option:
g++ -I [main_dir] main.cpp
Then when the compiler fails to find dir2/child2/file2.h in its first search, it will continue with the list of standard include search paths, and it should be found.
You need to manage CPPFLAGS in your Makefile.
CPPFLAGS="-I[main_dir]"
And compile application with receipt like this:
g++ $(CPPFLAGS) main.cpp -o main
Also it's recommended to read make style guides to write a good one Makefile. You can meet there tips for include folders declaration.
How do I create a custom library in GNU? What I mean is:
When we use #include < stdio.h> and printf
we can compile it with gcc main.c
Now I create my custom headers and .a/.so library files, I know I can set the environment variable C_INCLUDE_PATH and include my header files with #include<> instead of #include"". However, I still have to compile it with
gcc main.c -o program -L/whatever/ -lwahtever
(with set environment variable if using .so)
Is it possible to make it behave like #include< stdio.h> where I don't need to include the paths with corresponding command line arguments?
You actually don't need -L/whatever/, just -lwhatever. The first option supplies the path to your library, but you have already taken care of that with the #include and modifying C_INCLUDE_PATH. The second option tells the linker which library to link your executable with. An example of this is when using functions from the C math library, you #include <math.h>, but to compile, you still need the linker option -lmath. So to answer your question, no. You can remove the first option, but you must leave the second.
When a file contains an include line like this:
#include "name.h"
gcc (and other C compilers) search for the file "name.h" in the directory containing the file being compiled. This does not by default happen if the line looks like this:
#include <name.h>
Is there an option to gcc to make it behave this way in the latter case too? As noted in the gcc documentation, "-I. searches the compiler's current working directory for header files. That may or may not be the same as the directory containing the current file." In the case I am working on (importing external code that used a build environment that automatically added the containing directory to the search path into a system that doesn't have such a build facility), the current directory is unfortunately not the same. What can I do? I'd rather not have to specifically modify the files...