Issue defining a variable at link time in Makefile - c++

Ok so, im supposed to define a variable HASH_TABLE_SIZE at link time, so I would put that in my makefile.
my Makefile is as follows:
1 CC = g++
2 CFLAGS = -c -g -std=c++11 -Wall -W -Werror -pedantic -D HASH_TABLE_SIZE=10
3 LDFLAGS = -lrt
4
5 myhash : main.o hash.o hash_function.o
6 $(CC) $(LDFLAGS) main.o hash.o hash_function.o -o myhash
7
8 main.o : main.cpp hash.h
9 $(CC) $(LDFLAGS) main.cpp
10
11 hash.o : hash.cpp hash.h
12 $(CC) $(LDFLAGS) hash.cpp
13
14 hash_function.o : hash_function.cpp hash.h
15 $(CC) $(LDFLAGS) hash_function.cpp
16
17 clean :
18 rm *.o myhash
my Makefile seems correct to me, and I am putting -D HASH_TABLE_SIZE=10.
However, when I do make, I get this error:
In file included from main.cpp:3:0:
hash.h:24:27: error: 'HASH_TABLE_SIZE' was not declared in this scope
list<string> hashTable[HASH_TABLE_SIZE];
my Hash.h file is as follows:
1 /* This assignment originated at UC Riverside. The hash table size
2 should be defined at link time. Use -D HASH_TABLE_SIZE=X */
3
4 #ifndef __HASH_H
5 #define __HASH_H
6
7 #include <string>
8 #include <list>
9
10 using namespace std;
11
12 class Hash {
13
14 public:
15 Hash();
16 void remove(string word);
17 void print();
18 void processFile(string fileName);
19 bool search(string word);
20 void output(string fileName);
21 void printStats();
22
23 private:
24 list<string> hashTable[HASH_TABLE_SIZE];
25 int collisions;
26 int longestList;
27 double avgLength;
28
29 private:
30 int hf(string ins);
31 double newAvgListLen;
32
33 // put additional variables/functions below
34 // do not change anything above!
35
36 };
37
38 #endif
Why is this happening? Any help would be greatly appreciated.

The quick solution
You are not using CFLAGS in your recipes so it is having no effect.
It should work if you change lines 8 to 15 to:
8 main.o : main.cpp hash.h
9 $(CC) $(CFLAGS) main.cpp
10
11 hash.o : hash.cpp hash.h
12 $(CC) $(CFLAGS) hash.cpp
13
14 hash_function.o : hash_function.cpp hash.h
15 $(CC) $(CFLAGS) hash_function.cpp
Some extra details
-D is a compile time flag not a link time option.
CFLAGS is conventionally used to pass compile time flags to the compiler for a C program.
Normally CXXFLAGS would be used for a C++ program such as this and CXX to specify the C++ compiler. Make doesn't really mind though but it can make it easier to follow when conventions are used.
LDFLAGS is normally used for passing link time flags like -lrt so it only makes sense to use that on line 6, not in the compiling steps.

Related

Problems with user defined constructors in C++

Im having issues with a class constructors that i define. my .cpp's and .h compile on there own but once i try to use them in a main and construct a class it throws errors.
ive read about how not properly defining a user created constructor may cause the same error but im positive that everything is correct.
joust.cpp
#include "joust.h"
2 //create class construct for knight class
3 //set his name stam and put him on a horse
4 knight::knight (string n) : equipped_wep(5,5,"Basic Blade"){
5 name = n;
6 stamina = 100;
7 mounted = true;
8 }
9
10 void knight::show_stats() {
11 if (stamina) {
12 cout << name << " is not exhausted (stamina="<< stamina<< ") and is moun ted" << endl;
13 } else {
14 cout << name << " has passed out from exhaustion" << endl;
15 }
16 }
17 void knight::show_wep() {
18 cout << name << " is using " << equipped_wep.display_wep() << endl;
19 }
20
21 void knight::equip_weapon(weapon wep) {
22 equipped_wep = wep;
joust.h
13 #ifndef JOUST_H
14 #define JOUST_H
15
16 #include <iostream>
17 #include <fstream>
18 #include <vector>
19
20 using namespace std;
21
22 class weapon {
23 public:
24 weapon(float = 1, float = 1, string = "base");
25 void set(float, float);
26 string display_wep();
27 private:
28 float effectivness;
29 float weight;
30 string name;
31 };
32
33 class knight {
34 public:
35 knight( string = "base");
36 void show_stats();
37 void show_wep();
38 void equip_weapon(weapon wep);
39 private:
40 weapon equipped_wep;
41 string name;
42 int stamina;
43 bool mounted;
44 };
45
46
47 #endif
test.cpp
#include "joust.h"
2
3 int main() {
4 //knight jim("Rob the Third");
5 //jim.show_stats();
6 weapon c(15,12,"jard");
7
8 return 0;
9 }
makefile
test: test.o joust.o
2 g++ -std=c++11 joust.o test.o -o test
3 test.o: test.cpp joust.h
4 g++ -std=c++11 test.cpp
5 joust.o: joust.cpp joust.h
6 g++ -std=c++11 -c joust.cpp
7 clean:
8 rm -f joust.o
It should of just created a weapon object bust instead threw this error
make
g++ -std=c++11 test.cpp
Undefined symbols for architecture x86_64:
"weapon::weapon(float, float, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)", referenced from:
_main in test-501f47.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test.o] Error 1
There are two problems that you have:
First you need to build all source file together, or to create object files from each source file that you then link together.
The second error is that you don't define (implement) the weapon constructor anywhere.
The first problem is solved by adding the -c flag when building the source files. The -c flags tells GCC to create object files (the files ending in .o). You have it when building the joust.cpp source file, but seem to have forgotten it for the test.cpp source file.
The second problem should be pretty obvious how to solve: Implement the constructor function.

What do gcc preprocessed output lines of form hash sign + digit "# 1" mean?

While doing a bug report for CUDA's compiler, I ended up finding this strange behavior with gcc's preprocessing step. I currently use gcc 4.8.2.
Test file: test.cpp
#include <assert.h>
int main()
{
int a = 1;
assert (a >= 0);
assert (a
>= 0);
}
Command
gcc -E -x c++ -m64 -g -o "test.cpp4.ii" "test.cpp"
Result file: test.cpp4.ii
# 2 "test.cpp" 2
int main()
{
int a = 1;
((a >= 0) ? static_cast<void> (0) : __assert_fail ("a >= 0", "test.cpp", 6, __PRETTY_FUNCTION__));
((a >= 0) ? static_cast<void> (0) : __assert_fail ("a >= 0",
"test.cpp"
# 7 "test.cpp" 3 4
,
8
# 7 "test.cpp" 3 4
, __PRETTY_FUNCTION__))
;
The multiline assert seems to be processed differently, leading to these # 7 "test.cpp" 3 4 lines. What does that mean exactly?
Update
Apparently, gcc 4.7 gives # 7 "test.cpp" (without the last 2 numbers).
It looks like line markers. As you might have noted, there's no trivial relation between line numbers in the original and preprocessed file. # 7 in the preprocessed input indicates that the source of next line was line7 in the original (which was named test.cpp).
3 4 are flags, meaning "macro expansion from system header" and extern "C"
GCC documentation

Linking several LLVM C++ modules together segfaults in lli

I'm trying a very simple example with LLVM/clang and seem to fail.
I try the following:
clang++ -emit-llvm -c -x c++ -o main.bc -isystem include/ main.cc
clang++ -emit-llvm -c -x c++ -o test_class.bc -isystem include/ test_class.cc
llvm-link main.bc test_class.bc -o all.bc
lli all.bc
However, 4. fails (segfaults) with:
0 libLLVM-3.3.so 0x0000003b890f9e52 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1 libLLVM-3.3.so 0x0000003b890f9cb9
2 libpthread.so.0 0x0000003b8520efa0
3 libLLVM-3.3.so 0x0000003b89982790 llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const + 0
4 libLLVM-3.3.so 0x0000003b894bfb23
5 libLLVM-3.3.so 0x0000003b894c8dc3
6 libLLVM-3.3.so 0x0000003b8981b27f
7 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
8 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
9 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
10 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
11 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
12 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
13 libLLVM-3.3.so 0x0000003b894c6649
14 libLLVM-3.3.so 0x0000003b894c909c
15 libLLVM-3.3.so 0x0000003b8981b27f
16 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
17 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
18 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
19 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
20 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
21 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
22 lli 0x00000000004073cf main + 2527
23 libc.so.6 0x0000003b84621b75 __libc_start_main + 245
24 lli 0x000000000040a271
Stack dump:
0. Program arguments: lli all.bc
1. Running pass 'X86 Machine Code Emitter' on function '#main'
2. Running pass 'X86 Machine Code Emitter' on function '#_ZN10test_classC2ESs'
[1] 15327 segmentation fault (core dumped) lli all.bc
Do I have a fundamental missunderstanding on how this is supposed to work? My ultimate goal is to do the compilation
part using the libclang API, but for now understanding what I do wrong here would be awesome! Thanks!
I attached the source code for the example below:
include/test_class.h:
#ifndef __TEST_CLASS_H__
#define __TEST_CLASS_H__
#include <string>
#include <iostream>
struct test_class
{
test_class(std::string foo);
~test_class();
std::string foo;
};
#endif
test_class.cc:
#include <test_class.h>
test_class::test_class(std::string foo) : foo(foo)
{
std::cout << foo << std::endl;
}
test_class::~test_class(void)
{
}
main.cc:
#include <cstdlib>
#include <string>
#include <iostream>
#include <test_class.h>
int main(int argc, char** argv)
{
test_class test("foo");
return EXIT_SUCCESS;
}
In test_class you refer to std::string. I guess, calls to related functions are marked external if you have a look into the IR (eg: llvm-dis < all.bc).
If you compile to "normal" executable code, these calls are resolved by the linker.
Since you link manually with llvm-link you will have to provide IR-code for the C++ libraries, otherwise execution might fail.

Linux Stack trace dump

I'm coding a program and at some point during execution it crashes and print this stack-trace:
pure virtual method called
terminate called without an active exception
0 prog 0x08f04a98
1 prog 0x08f05147
2 0xb7802400 __kernel_sigreturn + 0
3 libc.so.6 0xb758fbb2 abort + 386
4 libstdc++.so.6 0xb778653f __gnu_cxx::__verbose_terminate_handler() + 335
5 libstdc++.so.6 0xb7784405
6 libstdc++.so.6 0xb7784442
7 libstdc++.so.6 0xb77850f5
8 prog 0x08f2cb1f proj::raw_ostream::write(char const*, unsigned int) + 159
9 prog 0x081df8fe
10 prog 0x081d079b
11 prog 0x08e8ac02 proj::Value::~Value() + 130
12 prog 0x082749ad
13 prog 0x08e1cd62 proj::Tiny::~Tiny() + 178
14 prog 0x08e1fc86 proj::Alloca::~Alloca() + 38
15 prog 0x08e252ac proj::Alloca::~Alloca() + 44
16 prog 0x088e9bbc
17 prog 0x088e9b64
18 prog 0x08d3782e
19 prog 0x08d36a46
20 prog 0x08d34e95 proj::Medium::~Medium() + 485
21 prog 0x08d34c9c proj::Medium::~Medium() + 44
22 prog 0x08d3753c
23 prog 0x08d36da4
24 prog 0x08d350ed proj::Medium::eraseFromParent() + 109
25 prog 0x08dc780d proj::Big::dropAllReferences() + 253
26 prog 0x08e530b9 proj::Module::dropAllReferences() + 137
27 prog 0x08e52ea0 proj::Module::~Module() + 64
28 prog 0x08c602cb proj::Engine::~Engine() + 155
29 prog 0x08743e00 proj::Controller::~Controller() + 192
30 prog 0x08743d2c proj::Controller::~Controller() + 44
31 prog 0x081cdee9
32 libc.so.6 0xb75912df
33 libc.so.6 0xb759134f
34 libc.so.6 0xb7578cae __libc_start_main + 238
35 prog 0x081cc501
What is the address on the third column? I guess they are function address but are they? seems that some virtual function is being called at somepoint, how do I know what virtual function is being called?
The third column is the program counter recorded on the stack so it will be a code address.
You need to look at whether you are calling pure virtuals within your destructors; most likely proj::Value::~Value() is calling a virtual that is pure in proj::Value.
Yes, they are function addresses. If you have the corresponding core file for that dump, and you had compiled with debugging symbols, you can load the core and executable in gdb, and use the command list *<address>. It will show you the line of code corresponding to that address.
Without seeing any code, I would guess write on raw_ostream is a virtual method.
The third column is the actual memory address that is being executed on the function stack (should be equal to the fourth column, which gives you the offset from the beginning of the named function).
The function stack is shown growing up: lines shown earlier are nested deeper in the call stack. In other way: your main is near the bottom of the list
The virtual function is called from proj::Value::~Value(), which calls proj::raw_ostream::write(char const*, unsigned int), which causes the exception

Weird Adobe Alchemy compiler fail

I'm trying to build a project using OpenCV with alchemy. My idea was to isolate the parts I need from OpenCV (v.2.2), compile them with alchemy g++ and link with my code statically. So here's what I do:
First I compile needed opencv sources one by one (I need core, imgproc and some others):
alc-on; for src in *.cpp ; do g++ -I../../include -DOSX -c -Wall -O3 -o ${PWD##*/}_`basename $src .cpp`.o $src ; done ; mv -v *.o ~/dev/cut/obj/
Then I try to build this simple test of Flash—OpenCV interaction and link it against all .o's I have built as above:
#include <opencv/cv.h>
#include "AS3.h"
void testCV()
{
cv::Mat a(3,3,CV_8UC1,cv::Scalar(1.0));
cv::Mat b(3,3,CV_8UC1,cv::Scalar(2.0));
cv::Mat c;
c=a+b;
}
static AS3_Val test(void* self, AS3_Val args)
{
testCV();
return 0;
}
int main()
{
AS3_Val testMethod = AS3_Function(NULL,test);
AS3_Val result = AS3_Object("test: AS3ValType",testMethod);
AS3_Release(testMethod);
AS3_LibInit(result);
return 0;
}
Next, assuming I have the source and all needed .o's in the same folder, I try to compile them as swc:
g++ -I../include -Wall -O3 -DOSX -swc test_cv.cpp *.o -o cvtest.swc
(Note: creating a library archive with 'ar rc' and 'ranlib' and linking against it has the same effect)
And at this point, I get the following error report from alchemy tools (I guess it's llvm):
Assertion failed: (TLI.isTypeLegal(VT) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file /Volumes/data/dev/FlaCC/llvm-2.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 2465.
0 llc 0x00636dfe _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 6078
1 llc 0x006373a2 _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 7522
2 libSystem.B.dylib 0x9125e05b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 libSystem.B.dylib 0x912eb5a5 raise + 26
5 libSystem.B.dylib 0x913016e4 abort + 93
6 libSystem.B.dylib 0x912ee20f __assert_rtn + 252
7 llc 0x003f3e2a _ZN4llvm11StoreSDNodeD1Ev + 90026
8 llc 0x003f5256 _ZN4llvm11StoreSDNodeD1Ev + 95190
9 llc 0x003f817c _ZN4llvm11StoreSDNodeD1Ev + 107260
10 llc 0x0040bc68 _ZN4llvm11StoreSDNodeD1Ev + 187880
11 llc 0x0040d3f2 _ZN4llvm11StoreSDNodeD1Ev + 193906
12 llc 0x0040f92e _ZN4llvm11StoreSDNodeD1Ev + 203438
13 llc 0x005d1926 _ZN4llvm12FunctionPassD1Ev + 20998
14 llc 0x005d1f3a _ZN4llvm12FunctionPassD1Ev + 22554
15 llc 0x005d20c5 _ZN4llvm12FunctionPassD1Ev + 22949
16 llc 0x00002e44 0x0 + 11844
17 llc 0x00001f36 0x0 + 7990
18 ??? 0x00000006 0x0 + 6
I found out that the problem comes from the file matop.o (matop.cpp from OpenCV core module), but I cannot throw it out of linking because it results in undefined sym error at runtime in flash (it cannot find cv::add, if I'm not mistaken).
Can anyone suggest any way to identify the real problem and any (even dirty hacking — style) workaround for it?
My thread on the problem and workarounds at adobe alchemy forums: http://forums.adobe.com/message/3891743#3891743
Dirty hack workaround: remove defined section from top of OpenCV2.0 core arithm.cpp between
#if CV_SSE2
...
#else
and leave only the else-section. This would work for the example above.
Other parts of OpenCV might need more mindbogglingly exquisite hacking.