After switching from GCC to LLVM for a codebase which relies on Protobuf, I keep getting a segfault during "initialization". No Protobuf r/w is being executed when the exception occurs.
The stack trace looks like this:
__dynamic_cast (#__dynamic_cast:13)
google::protobuf::Message const* google::protobuf::internal::down_cast<google::protobuf::Message const*, google::protobuf::MessageLite const>(google::protobuf::MessageLite const*) (#google::protobuf::Message const* google::protobuf::internal::down_cast<google::protobuf::Message const*, google::protobuf::MessageLite const>(google::protobuf::MessageLite const*):25)
google::protobuf::Message::CheckTypeAndMergeFrom(google::protobuf::MessageLite const&) (#google::protobuf::Message::CheckTypeAndMergeFrom(google::protobuf::MessageLite const&):12)
google::protobuf::MessageLite::ParseFromArray(void const*, int) (#google::protobuf::MessageLite::ParseFromArray(void const*, int):68)
google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) (#google::protobuf::EncodedDescriptorDatabase::Add(void const*, int):23)
google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (#google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int):17)
protobuf_google_2fprotobuf_2fany_2eproto::AddDescriptorsImpl() (#protobuf_google_2fprotobuf_2fany_2eproto::AddDescriptorsImpl():9)
__pthread_once_slow (#__pthread_once_slow:58)
___lldb_unnamed_symbol7928 (#___lldb_unnamed_symbol7928:24)
and the method in which it occurs is in protobuf/message.cc:
void Message::MergeFrom(const Message& from) {
auto* class_to = GetClassData();
auto* class_from = from.GetClassData();
auto* merge_to_from = class_to ? class_to->merge_to_from : nullptr;
if (class_to == nullptr || class_to != class_from) {
merge_to_from = [](Message* to, const Message& from) {
ReflectionOps::Merge(from, to);
};
}
merge_to_from(this, from);
}
at from.GetClassData().
I've built Protobuf locally (Ubuntu 20.04) using various configurations with similar results. The most successful configuration being:
./configure CC=clang CXX="clang++ -std=c++11 -stdlib=libstdc++" --disable-shared
I've also seen instructions online suggesting to build Protobuf using libc++, in which case my code fails to link.
Here's my includes:
#include <iostream>
#include <string>
#include <cstring>
#include <stdio.h> //for snprintf
#include <libscrypt.h>
#include <sqlite3.h>
#include "generator.h" //has no dependencies
And here's my g++ 4.2.1 command with compilation errors:
# g++ -I/usr/local/include -L /usr/local/lib test.cpp generator.cpp -o test -lscrypt -lsqlite3
/tmp//cctxmw4C.o: In function `insertUser()':
test.cpp:(.text+0x607): undefined reference to `libscrypt_salt_gen(unsigned char*, unsigned long)'
test.cpp:(.text+0x6c3): undefined reference to `libscrypt_scrypt(unsigned char const*, unsigned long, unsigned char const*, unsigned long, unsigned long long, unsigned int, unsigned int, unsigned char*, unsigned long)'
collect2: ld returned 1 exit status
Similar C code compiles fine with GCC. I do not believe that the order of the parameters is the problem -- I have tried multiple variations, including moving the -I, -L, and both -l flags. Both scrypt and sqlite3 are C libraries, and sqlite3 throws no errors despite having the header and shared library in -I and -L respectively.
Look at the solution here.
Using C Libraries for C++ Programs
extern "C"{
void c_function_prototype();
}
or
extern "C" void c_function_prototype();
If you have it see "The C++ Programming Language (Stoustrup) 4th Edition" p429
I have a function in C++ that uses data types like vector and map from STL. Here is some sample code:
mylib.cpp
#include "mylib.h"
#include<vector>
using namespace std;
int summation(int n) {
vector<int> numbers;
int sum = 0;
for(int i = 1; i <=n; i++)
numbers.push_back(i);
for(int j = 0; j < numbers.size(); j++)
sum += numbers[j];
return sum;
}
I created a header file as follows:
mylib.h
#ifdef _cplusplus
extern "C" {
#endif
extern int summation(int n);
#ifdef _cplusplus
};
#endif
The C++ file was compiled into the obejct code using the command
g++ -o mylib.o -c mylib.cpp
Then, I wrote a C program in order to use the function summation from it.
main.c
#include<stdio.h>
#include "mylib.h"
int main() {
int n;
scanf("%d", &n);
printf("%d", summation(n));
return 0;
}
Now, when I compile the C file above using gcc,
gcc main.c mylib.o
I get the following error
/tmp/ccAMN2ld.o: In function `main':
main.c:(.text+0x33): undefined reference to `summation'
mylib.o: In function `std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&)':
mylib.cpp:(.text._ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi[_ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi]+0x26e): undefined reference to `__cxa_begin_catch'
mylib.cpp:(.text._ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi[_ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi]+0x2d7): undefined reference to `__cxa_rethrow'
mylib.cpp:(.text._ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi[_ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi]+0x2df): undefined reference to `__cxa_end_catch'
mylib.o: In function `std::vector<int, std::allocator<int> >::_M_check_len(unsigned long, char const*) const':
mylib.cpp:(.text._ZNKSt6vectorIiSaIiEE12_M_check_lenEmPKc[_ZNKSt6vectorIiSaIiEE12_M_check_lenEmPKc]+0x5b): undefined reference to `std::__throw_length_error(char const*)'
mylib.o: In function `__gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long)':
mylib.cpp:(.text._ZN9__gnu_cxx13new_allocatorIiE10deallocateEPim[_ZN9__gnu_cxx13new_allocatorIiE10deallocateEPim]+0x1c): undefined reference to `operator delete(void*)'
mylib.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
mylib.cpp:(.text._ZN9__gnu_cxx13new_allocatorIiE8allocateEmPKv[_ZN9__gnu_cxx13new_allocatorIiE8allocateEmPKv]+0x2c): undefined reference to `std::__throw_bad_alloc()'
mylib.cpp:(.text._ZN9__gnu_cxx13new_allocatorIiE8allocateEmPKv[_ZN9__gnu_cxx13new_allocatorIiE8allocateEmPKv]+0x3c): undefined reference to `operator new(unsigned long)'
mylib.o:(.eh_frame+0x4b): undefined reference to `__gxx_personality_v0'
collect2: error: ld returned 1 exit status
It is imperative that I use gcc to compile the C file. Is there a way to make it work?
I tried looking for solution and stumbled upon the links below,
How to call C++ function from C?
Elegantly call C++ from C
http://www.cplusplus.com/forum/general/8997/
but couldn't find a solution to my problem.
Compile the C file by itself with the C compiler:
gcc -c cfile.c
then link all the files with the C++ compiler:
g++ -o a.out main.o cfile.o mylib.o
Note that you must compile the file with the main function with the C++ compiler. Any other files can be compiled with either, though you need extern "C" declarations to be able to call C code from C++ or create C++ functions that can be called from C
I have build all the file in g++, am not getting linking error. can you build all the source file to gcc or g++.
I have install leveldb in my home directory ~/local like this.
[~/temp/leveldb-1.15.0] $ make
[~/temp/leveldb-1.15.0] $ cp -av libleveldb.* $HOME/local/lib/
[~/temp/leveldb-1.15.0] $ cp -av include/leveldb $HOME/local/include/
My c++ program like this：
#include <assert.h>
#include <iostream>
#include "leveldb/db.h"
using namespace std;
int main(int argc,char * argv[])
{
leveldb::DB* db;
leveldb::Options options;
options.create_if_missing = true;
std::string dbpath = "tdb";
leveldb::Status status = leveldb::DB::Open(options, dbpath, &db);
assert(status.ok());
std::string key1 = "grz";
std::string key2 = "grz-rt#63.com";
cout<<"Open db OK"<<std::endl;
std::string value;
leveldb::Status s ;
s = db->Put(leveldb::WriteOptions(), key1, key2);/*key1和key2作为一对key-value对插入*/
s = db->Get(leveldb::ReadOptions(), key1, &value);/*根据key返回对应的value值*/
cout<<value<<std::endl;
delete db;/*删除数据库*/
return 0;
}
I compile this C++ program like this：
g++ -o Main Main.cpp ~/local/lib/libleveldb.a -lpthread -I ~/local/include/
But I get the error like this：
/public/home/kli/local/lib/libleveldb.a(table_builder.o): In function `leveldb::TableBuilder::WriteBlock(leveldb::BlockBuilder*, leveldb::BlockHandle*)':
table_builder.cc:(.text+0x678): undefined reference to `snappy::MaxCompressedLength(unsigned long)'
table_builder.cc:(.text+0x6b2): undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'
/public/home/kli/local/lib/libleveldb.a(format.o): In function `leveldb::ReadBlock(leveldb::RandomAccessFile*, leveldb::ReadOptions const&, leveldb::BlockHandle const&, leveldb::BlockContents*)':
format.cc:(.text+0x5de): undefined reference to `snappy::GetUncompressedLength(char const*, unsigned long, unsigned long*)'
format.cc:(.text+0x64e): undefined reference to `snappy::RawUncompress(char const*, unsigned long, char*)'
collect2: ld returned 1 exit status
I don't know what's wrong.
I am new to Linux. Thank you very much!
libleveldb.a misses Snappy when being linked which would be probably in libsnappy.a in the same directory.
Looks like the Makefile is incomplete.
With the current install, you need to edit the Makefile to link against snappy and to include -L/usr/local/lib instead of -L/usr/local/include.
(Will post pull request later)
Does anyone know if it's kosher to pass a boost::unordered_set as the first parameter to boost::split? Under libboost1.42-dev, this seems to cause problems. Here's a small example program that causes the problem, call it test-split.cc:
#include <boost/algorithm/string/classification.hpp>
#include <boost/algorithm/string/split.hpp>
#include <boost/unordered_set.hpp>
#include <string>
int main(int argc, char **argv) {
boost::unordered_set<std::string> tags_set;
boost::split(tags_set, "a^b^c^",
boost::is_any_of(std::string(1, '^')));
return 0;
}
Then, if I run the following commands:
g++ -o test-split test-split.cc; valgrind ./test-split
I get a bunch of complaints in valgrind like the one that follows (I also sometimes see coredumps without valgrind, though it seems to vary based on timing):
==16843== Invalid read of size 8
==16843== at 0x4ED07D3: std::string::end() const (in /usr/lib/libstdc++.so.6.0.13)
==16843== by 0x401EE2: unsigned long boost::hash_value<char, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /tmp/test-split)
...
==16843== by 0x402248: boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >& boost::algorithm::split<boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >, char const [26], boost::algorithm::detail::is_any_ofF<char> >(boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >&, char const (&) [26], boost::algorithm::detail::is_any_ofF<char>, boost::algorithm::token_compress_mode_type) (in /tmp/test-split)
==16843== by 0x40192A: main (in /tmp/test-split)
==16843== Address 0x5936610 is 0 bytes inside a block of size 32 free'd
==16843== at 0x4C23E0F: operator delete(void*) (vg_replace_malloc.c:387)
==16843== by 0x4ED1EE8: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
==16843== by 0x404A8B: void boost::unordered_detail::hash_unique_table<boost::unordered_detail::set<boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> > >::insert_range_impl<boost::transform_iterator<boost::algorithm::detail::copy_iterator_rangeF<std::string, char const*>, boost::algorithm::split_iterator<char const*>, boost::use_default, boost::use_default> >(std::string const&, boost::transform_iterator<boost::algorithm::detail::copy_iterator_rangeF<std::string, char const*>, boost::algorithm::split_iterator<char const*>, boost::use_default, boost::use_default>, boost::transform_iterator<boost::algorithm::detail::copy_iterator_rangeF<std::string, char const*>, boost::algorithm::split_iterator<char const*>, boost::use_default, boost::use_default>) (in /tmp/test-split)
...
==16843== by 0x402248: boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >& boost::algorithm::split<boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >, char const [26], boost::algorithm::detail::is_any_ofF<char> >(boost::unordered_set<std::string, boost::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >&, char const (&) [26], boost::algorithm::detail::is_any_ofF<char>, boost::algorithm::token_compress_mode_type) (in /tmp/test-split)
==16843== by 0x40192A: main (in /tmp/test-split)
This is a Debian Squeeze box; here's my relevant system info:
$ g++ --version
g++ (Debian 4.4.5-2) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ dpkg -l | grep boost
ii libboost-iostreams1.42.0 1.42.0-4 Boost.Iostreams Library
ii libboost1.42-dev 1.42.0-4 Boost C++ Libraries development files
$ uname -a
Linux gcc44-buildvm 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux
However, the code seems to work fine if I downgrade libboost1.42-dev to libboost1.40-dev. So is this a bug in boost 1.42, or am I misusing boost::split by passing in a container that can't handle sequences? Thanks!
This was confirmed on the boost-users mailing list to be a bug in the boost::unordered_set implementation. There is a patch available on the mailing list, and a fix will be checked in soon, hopefully in time for boost 1.45.
Boost-users: patch
Boost-users: confirmation
Thanks everyone for looking into this!
I think the answer should be yes.
Reading the headers (split.hpp and iter_find.hpp) split takes a SequenceSequenceT& Result as its first argument, which it passes to iter_split which range-constructs it from two boost::transform_iterators:
SequenceSequenceT Tmp(itBegin, itEnd);
Result.swap(Tmp);
return Result;
So all it needs of this type is that it has a constructor that takes a pair of iterators which dereference to std::string (or, technically, to BOOST_STRING_TYPENAME). And has a .swap() member.. and has a SequenceSequenceT::iterator type whose type is std::string.
proof:
#include <boost/algorithm/string/classification.hpp>
#include <boost/algorithm/string/split.hpp>
#include <string>
#include <iterator>
#include <algorithm>
#include <iostream>
struct X
{
typedef std::iterator<std::forward_iterator_tag,
std::string, ptrdiff_t, std::string*, std::string&>
iterator;
X() {}
template<typename Iter> X(Iter i1, Iter i2)
{
std::cout << "Constructed X: ";
copy(i1, i2, std::ostream_iterator<std::string>(std::cout, " " ));
std::cout << "\n";
}
void swap(X&) {}
};
int main()
{
X x;
boost::split(x, "a^b^c^", boost::is_any_of(std::string(1, '^')));
}
I think that unordered_set<std::string> should satisfy these requirements as well.
Apparently, the answer is no yes.
Using the following code, I get compile-time warnings and a runtime assert (Visual C++ v10) on the unordered_set while the vector works fine (apart from an empty string in the last element, due to the trailing '^').
boost::unordered_set<std::string> tags_set;
vector<string> SplitVec; // #2: Search for tokens
boost::split( SplitVec, "a^b^c^", boost::is_any_of("^") );
boost::split( tags_set, "a^b^c^", boost::is_any_of("^") );
Iterator compatibility between source (string) and the target container is the issue. I would post the warning error, but it's one of those "War and Peace" template warnings.
EDIT:
This looks like a bug in Boost unordered_set? When I use the following, it works as you would expect:
std::unordered_set<std::string> tags_set_std;
boost::split( tags_set_std, string("a^b^c^"), boost::is_any_of(string("^")) );