I installed a fresh version of Ubuntu 16.04.4 LTS and was able to compile my project with cmake . and make and this g++-5 command
g++-5 src/*.cpp -pthread -I extern/sleepy-discord/include -I
extern/poco-1.9.0/Foundation/include -I extern/poco-1.9.0/JSON/include
-I extern/poco-1.9.0/Net/include -I extern/poco-1.9.0/Util/include -L extern/sleepy-discord/lib/linux -L extern/poco-1.9.0/lib/linux
-std=c++11 -o bin/tipbot -lPocoJSON -lPocoUtil -lPocoNet -lPocoFoundation -lsleepy_discord -lcurl -lssl -lcrypto
Everything built successfully without error but on Travis CI it gives hundreds of linker errors
Travis.yml:
dist: trusty
sudo: false
language: cpp
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- g++-5
- libcurl4-openssl-dev
- openssl
script:
- ls extern/sleepy-discord/lib/linux
- ls extern/poco-1.9.0/lib/linux
- g++-5 src/*.cpp -pthread -I extern/sleepy-discord/include -I extern/poco-1.9.0/Foundation/include -I extern/poco-1.9.0/JSON/include -I extern/poco-1.9.0/Net/include -I extern/poco-1.9.0/Util/include -L extern/sleepy-discord/lib/linux -L extern/poco-1.9.0/lib/linux -std=c++11 -o bin/tipbot -lPocoJSON -lPocoUtil -lPocoNet -lPocoFoundation -lsleepy_discord -lcurl -lssl -lcrypto
This is the error, it obviously found the libPocoJSON.a file but I don't understand why it says "undefined reference to" if it found the .a file and it found the C++11 template libraries.
extern/poco-1.9.0/lib/linux/libPocoJSON.a(ParserImpl.o): In function
Poco::JSON::ParserImpl::stripComments(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >&) [clone .part.23]':
ParserImpl.cpp:(.text+0x91): undefined reference to
std::__cxx11::basic_string,
std::allocator >::_M_erase(unsigned long, unsigned long)'
extern/poco-1.9.0/lib/linux/libPocoJSON.a(ParserImpl.o): In function
void std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_M_construct<char*>(char*, char*,
std::forward_iterator_tag) [clone .isra.68]':
ParserImpl.cpp:(.text+0x1f9): undefined reference to
std::__cxx11::basic_string,
std::allocator >::_M_create(unsigned long&, unsigned long)'
extern/poco-1.9.0/lib/linux/libPocoJSON.a(ParserImpl.o): In function
`Poco::JSON::ParserImpl::handle()':
Full Travis report:
https://travis-ci.org/Brandantl/IntenseCoin-TipBot/builds/363978290?utm_source=github_status&utm_medium=notification
Repo:
https://github.com/Brandantl/IntenseCoin-TipBot
Can also compile with cmake .;make
The problem is that you mixed use the c++11 string with the c++03 string, which have different implementation.
Maybe, the poco library or other library on your Travis CI server is not compiled with c++11 flag. Recompile it with -std=c++11 or replace it with the one on your local machine.
Related
I am writing a program using gRPC in the language c++. I have installed gRPC using the command brew install grpc on a MacOS I also have the most up to date version of protobuf. When I create a basic program using gRPC I compile them using the following commands:
protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/test.proto
Which creates the test.pb.h and test.pb.cc files
Then the command protoc -I . --grpc_out=. --plugin=protoc-gen-grpc=/usr/local/Cellar/grpc/1.45.2/bin/grpc_cpp_plugin test.proto which creates the test.pb.h and test.pb.cc files
I then run the command g++ -std=c++11 -stdlib=libc++ test.cpp test.grpc.pb.cc -L/usr/local/lib -lprotobuf to compile, where the main c++ file is test.cpp I then get some of the following linkage errors:
"grpc::ClientContext::ClientContext()", referenced from:
MathTestClient::sendRequest(int, int) in test-e2eddc.o
"grpc::ClientContext::~ClientContext()", referenced from:
MathTestClient::sendRequest(int, int) in test-e2eddc.o
"grpc::CreateChannel(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::shared_ptr<grpc::ChannelCredentials> const&)", referenced from:
Run() in test-e2eddc.o
"grpc::InsecureChannelCredentials()", referenced from:
Run() in test-e2eddc.o
"mathtest::MathRequest::MathRequest(google::protobuf::Arena*, bool)", referenced from:
mathtest::MathRequest::MathRequest() in test-e2eddc.o
"mathtest::MathRequest::~MathRequest()", referenced from:
MathTestClient::sendRequest(int, int) in test-e2eddc.o
Which makes sense, judging based off the fact that in the file grcpp/impl/codgen/client_context.h the linkage errors would obviously be there because client context is defined as the following:
class ClientContext {
public:
ClientContext();
~ClientContext();
or with the CreateChannel function it is defined in create_channel.h file as
std::shared_ptr<Channel> CreateChannel(
const grpc::string& target,
const std::shared_ptr<ChannelCredentials>& creds);
In my main c++ file, I only use the following include from gRPC: #include <grpcpp/grpcpp.h>
Are there other include files from gRPC that I need to include which define these functions?
I ended up figuring out my problem if anyone else has installed grpc the same way using homebrew as I did. make sure that on top of the brew install grpc command is run that the commands brew install protobuf and brew install abseil
Next is to find out the paths of all of these using the commands brew info grpc, brew info protobuf and brew info abseil for myself personally the paths are:
/usr/local/Cellar/abseil/20211102.0
/usr/local/Cellar/grpc/1.45.2
/usr/local/Cellar/protobuf/3.19.4
Then the $PKG_CONFIG_PATH needs to be setup, if this does not already exist and there is an error if you run echo $PKG_CONFIG_PATH you can run brew install pkg-config the $PKG_CONFIG_PATH is defined by all the previous paths, with the added path of /lib/pkgconfig which then the $PKG_CONFIG_PATH can be defined as
export PKG_CONFIG_PATH=/usr/local/Cellar/grpc/1.45.2/lib/pkgconfig:/usr/local/Cellar/protobuf/3.19.4/lib/pkgconfig:/usr/local/Cellar/abseil/20211102.0/lib/pkgconfig
After that is all done, and you have the main c++ file and the proto file, mine were named test.cpp and test.proto respectively, the following commands can be run to make it compile correctly and be able to get and then run ./test
>>> protoc --cpp_out=. test.proto
>>> g++ -std=c++11 `pkg-config --cflags protobuf grpc` -c -o test.pb.o >>> test.pb.cc
>>> protoc --grpc_out=. --plugin=protoc-gen->>> grpc=/usr/local/Cellar/grpc/1.45.2/bin/grpc_cpp_plugin test.proto
>>> g++ -std=c++11 `pkg-config --cflags protobuf grpc` -c -o test.grpc.pb.o test.grpc.pb.cc
>>> g++ -std=c++11 `pkg-config --cflags protobuf grpc` -c -o test.o test.cpp
>>> g++ test.pb.o test.grpc.pb.o test.o -L/usr/local/lib `pkg-config --libs >>> protobuf grpc++` -lgrpc++_reflection -ldl -o test
>>> rm test.grpc.pb.cc test.pb.cc
I have a library (let's call it libmylib.so) which was meant to be built using a docker running Ubuntu 16. I would like to use this library in a program (let's call it myapp) I wish to compile on my raspberry Pi running Raspbian.
When compiling, I get an output log of this form:
[25%] Building CXX object example1.cpp.o
[50%] Building CXX object example2.cpp.o
[75%] Building CXX object example3.cpp.o
[100%] Linking CXX executable target
And then a bunch of error of the form:
undefined reference to `VTT for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >#GLIBCXX_3.4.21'
undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#GLIBCXX_3.4.21'
collect2: error: ld returned 1 exit status
From what I could find on the web, this seems due to the fact that I am not compiling libmylib.so and myapp with the same compiler.
I am using g++ in both cases, but not the same version, as can be seen when I call g++ --version on both device.
From my docker:
root#3ea34286736e:/usr/bin# g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609
From my raspberry PI
pi#raspberrypi:/usr/bin $ g++ --version
g++ (Raspbian 4.9.2-10+deb8u1) 4.9.2
Is this a complete deal breaker or is there a way to make it work?
EDIT: Here is what I read that makes me assume it is a compiler version problem.
This and this seemed to be similar errors, to which the fix was to add to the cmake of myapp:
add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0)
which did not work.
Adding this flag to the compile options of libmylib.so reduced the number of undefined reference errors from 10 to 1. More precisely:
undefined reference to `std::invalid_argument::invalid_argument(char const*)#GLIBCXX_3.4.21'
Compiling libmylib as a static library rather than shared somehow fixed the problem.
I am trying to build a software package from source with make in Centos 6.5 which was successfully built in Fedora 8.
I made a few changes to the files and downgrade a few dependencies in Centos.
When I do make, I get a linker error:
/home/wjn/Desktop/samPro/src/graphEdit.o:
In function `GW::graphEdit::setPoints(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': graphEdit.cpp:(.text+0x88): undefined reference to `bool GW::GraphUtils::create<GW::MathVector<double, 3, GW::MathVectorColumn>
>(GW::Graph<double, 3, GW::GraphColumn>&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char, char, char)' collect2: ld returned 1 exit status
I checked the gcc command initiated by make, it is:
/usr/bin/g++ -D_GNU_SOURCE -O3 -mfpmath=sse -finline-limit=1000 -shared -Xlinker --no-undefined -Wl,-soname,libGraphImg.so
-o /home/wjn/Desktop/samPro/lib/graphImg.so /home/wjn/Desktop/samPro/src/graphType.o
/home/wjn/Desktop/samPro/src/graphCalibration.o
/home/wjn/Desktop/samPro/src/graphEdit.o
/home/wjn/Desktop/samPro/src/imgMorph.o
-L/home/wjn/Desktop/samPro/lib -Wl,
-rpath-link=/home/wjn/Desktop/samPro/lib -Wl,
-Bdynamic -lpthread -lm -lc
So I check graphUtils.h and graphUtils.cpp, bool GW::GraphUtils::create is properly defined but there is no graphUtils.o.
It is perfectly built in Fedora 8, so I am guessing it is a compiler version problem?
Centos has GCC 4.4.7 and Fedora has 4.1.2, could this be the problem? What can I do to solve this if I don't want to use the old GCC to build it.
I am compiling my C++ application and want to link it to mono. I am using OpenSusE. I have install mono-complete and glibc-devel-static packages. I am compiling as below -
$>g++ --static monoapp.cpp `pkg-config --cflags --libs mono` -I /usr/include/mono-2.0
/tmp/ccGfpBjX.o: In function `Launch(char const*, char const*, int, char const* const*, char const*)':
monoapp.cpp:(.text+0x23e): undefined reference to `mono_set_dirs'
monoapp.cpp:(.text+0x24f): undefined reference to `mono_jit_init_version'
monoapp.cpp:(.text+0x28b): undefined reference to `mono_domain_assembly_open'
monoapp.cpp:(.text+0x2c2): undefined reference to `mono_jit_exec'
collect2: error: ld returned 1 exit status
UPDATE 1 - I tried giving -lmono to linker but it complains about -lmono not found. Below is output of locate command.
$>locate libmono
/usr/lib64/libmono-2.0.a
/usr/lib64/libmono-2.0.so
/usr/lib64/libmono-2.0.so.1
/usr/lib64/libmono-2.0.so.1.0.0
Above output clearly shows that libmono is present.
UPDATE -2 Output of pkg-config is empty
$>pkg-config --cflags --libs mono
$>
UPDATE -3- I tried setting up PKG_CONFIG_PATH so that it can find mono.pc file but still it did not work
Please help.
Thanks,
Omky
I solved this by providing full path to static lib as -
g++ --static monoapp.cpp pkg-config --cflags --libs mono -I /usr/include/mono-2.0 -L /usr/lib64/ -lmono
I have tried building poco (poco-1.4.6p4) in several ways, all seem to build fine. However, when linking against it, all the different ways I have tried to build poco give error below. No matter what I choose, it appears that poco is being built with the clang++.
What is strange is that before I upgraded from Mountain Lion to Mavericks, none of this happened.
./configure --Darwin64 --shared
and
./configure --Darwin64-gcc --shared --no-tests
and
./configure --Darwin64-clang-libc++ --shared --no-tests
All the above seem to build fine.
But when I link against any of them, they all give the error below when linking against it.
Making all in compiler
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -lfix8 -lPocoFoundation -lPocoNet -lPocoUtil -L../runtime -lz -o f8c f8c.o f8cutils.o f8precomp.o
libtool: link: g++ -g -O2 -Wall -o .libs/f8c f8c.o f8cutils.o f8precomp.o -Wl,-bind_at_load /Users/ivanfigueredo/Downloads/fix8/runtime/.libs/libfix8.dylib -lpthread -lPocoFoundation -lPocoNet -lPocoUtil -L../runtime -lz
Undefined symbols for architecture x86_64:
"Poco::RegularExpression::RegularExpression(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, bool)", referenced from:
FIX8::RegExp::RegExp(char const*, int) in f8c.o
"Poco::RegularExpression::match(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, std::vector<Poco::RegularExpression::Match, std::allocator<Poco::RegularExpression::Match> >&, int) const", referenced from:
_main in f8c.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [f8c] Error 1
make: *** [all-recursive] Error 1
Configure generally will pay attention to CC and CXX environment variables to allow you to change compilers the software will build with. Try and adjust these settings.