This question doesn't address a specific problem I need solved, it is a question about the reasons for solutions.
I wrote some code in C++ that relied on the cryptopp library, specifically version 5.6.2.
I intended this code to be run on my Raspberry Pi eventually (running Raspbian), but it's much slower than my laptop so I did all of the development and testing there, in Linux Mint.
When compiling on my laptop I used this command:
g++ -o sim-test sim.cpp -lcryptopp
Today I ran the code for the first time on my Raspberry Pi and I ran into problems.
Specifically when trying to compile I got this:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../libcryptopp.so: undefined reference to `pthread_key_create'
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../libcryptopp.so: undefined reference to `pthread_getspecific'
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../libcryptopp.so: undefined reference to `pthread_key_delete'
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../libcryptopp.so: undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
So I tried adding pthread to the path and it compiled fine. But when I ran my program I immediately got a segfault. GDB's stacktrace is rather long but here it is:
#0 CryptoPP::BufferedTransformation::ChannelPut2 (this=0x6e080, channel=..., begin=0x6d624 "\330<\244\333\177\034a\216", length=8, messageEnd=0, blocking=true) at cryptlib.cpp:356
#1 0xb6e67248 in CryptoPP::StringStore::CopyRangeTo2 (this=<optimized out>, target=..., begin=@0xbefff238: 0, end=18446744073709551615, channel=..., blocking=true) at filters.cpp:1069
#2 0xb6e67198 in CryptoPP::StringStore::TransferTo2 (this=0xbefff4c0, target=..., transferBytes=@0xbefff268: 18446744073709551615, channel=..., blocking=true) at filters.cpp:1059
#3 0xb6e126a8 in TransferMessagesTo2 (blocking=true, channel=..., messageCount=@0xbefff2ac: 0, target=..., this=0xbefff4c0) at cryptlib.cpp:509
#4 CryptoPP::BufferedTransformation::TransferMessagesTo2 (this=0xbefff4c0, target=..., messageCount=@0xbefff2ac: 0, channel=..., blocking=true) at cryptlib.cpp:494
#5 0xb6e12890 in CryptoPP::BufferedTransformation::TransferAllTo2 (this=0xbefff4c0, target=..., channel=..., blocking=<optimized out>) at cryptlib.cpp:555
#6 0x0004ebb8 in CryptoPP::SourceTemplate<CryptoPP::StringStore>::PumpAll2(bool) ()
#7 0x0003668c in CryptoPP::Source::PumpAll() ()
#8 0x000366e4 in CryptoPP::Source::SourceInitialize(bool, CryptoPP::NameValuePairs const&) ()
#9 0x00036a80 in CryptoPP::StringSource::StringSource(std::string const&, bool, CryptoPP::BufferedTransformation*) ()
#10 0x00030a14 in AESEncrypt(std::string&, std::string&, unsigned char*, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&) ()
#11 0x00032270 in Simulation(std::string&, std::string&, void (*)(CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&, int*), void (*)(CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&, unsigned char**, int*, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&), void (*)(std::string&, std::string&, unsigned char*, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&), void (*)(std::string&, std::string&, unsigned char*, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&), void (*)(std::string&, std::string&, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&), void (*)(std::string&, std::string&, CryptoPP::SecBlock<unsigned char, CryptoPP::AllocatorWithCleanup<unsigned char, false> >&), int*, int*, int*) ()
#12 0x000326b0 in main ()
So I do some searching and I come across this post:
cryptopp on centos4.8 segmentation fault when link with pthread
The asker has -static in their g++ command so I figure I'll give that a shot, and it works! My program runs just fine with no segfaults!
To be clear this is my final g++ command string:
g++ -o sim-test sim.cpp -lcryptopp -static -pthread
But it ran just fine in Mint before, so why did I need to change the command string so much to get it to work on Raspbian?
I should also note that I've tested it and this command string compiles and runs just fine in Mint...