I am running ubuntu 16.04 with gcc.
My q.ccp file is
#include <google/protobuf/generated_message_util.h>
#include <google/protobuf/repeated_field.h>
#include <google/protobuf/extension_set.h>
#include <google/protobuf/generated_message_reflection.h>
#include <google/protobuf/generated_message_util.h>
#include <google/protobuf/stubs/common.h>
#include <google/protobuf/descriptor.h>
int main(int argc, char **argv)
{
google::protobuf::Message* msg;
const google::protobuf::Descriptor* message_desc = msg->GetDescriptor();
const google::protobuf::FieldDescriptor * fd_name = message_desc->FindFieldByName("name");
return 0;
}
command used for compilation:
g++ -D_GLIBCXX_USE_CXX11_ABI=0 q.cpp -L/usr/lib/x86_64-linux-gnu /usr/local/lib/libprotobuf.a -lpthread
protoc --version returns: 2.2.0
gcc --version
gcc (Ubuntu 4.8.5-4ubuntu2) 4.8.5
Copyright (C) 2015 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.
compile error:
/tmp/cciGJPqq.o: In function `main':
q.cpp:(.text+0x5f): undefined reference to `google::protobuf::Descriptor::FindFieldByName(std::string const&) const'
collect2: error: ld returned 1 exit status
But when I leave the -D_GLIBCXX_USE_CXX11_ABI=0 option, I get no compile error. But the problem is that I running the executable on different system which require compilation with this option for the program to run.
If your compilation succeeds only with D_GLIBCXX_USE_CXX11_ABI=0, then you may be using a shared library (libprotobuf) that is precompiled using the same or using an older ABI, like gcc 4.8.
I would check the g++ version. It may be > 5, which would have the newer ABI.
Related
Hi: I'm using WSL+Ubuntu20.04 on win10, installed g++ using sudo apt-get.
g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 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.
Fairly new, then I have this code modified from cppreference.com:
#include <iostream>
#include <thread>
#include <shared_mutex>
#include <mutex>
using namespace std;
class Counter {
int value;
shared_mutex m;
public:
...
My command line is:
g++ rwlock.cpp -std=c++11
It doesn't compile, saying that:
error: ‘shared_mutex’ does not name a type
10 | shared_mutex m;
And some other errors, all point to that I don't have these c++11 types defined.
Did I missing anything while installing g++ or should add more command line options when compiling?
Thanks!
The std::shared_mutex was not provided until c++ 17. https://en.cppreference.com/w/cpp/thread/shared_mutex
So to fix this issue, you just need to change the compilation command to
g++ rwlock.cpp -std=c++17
Hi am trying to compile a src file by linking an external library.
Getting below error
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
make -f GNUmakefile
g++ -m32 -D_POSIX_PTHREAD_SEMANTICS -g -Wl,--version-script=fix.txt -D_GNU_SOURCE -I../include ConnectionAndAuthExample.cpp -o ../Linux/ConnectionAndAuthExample_32 -L../Linux -lsomelib
../Linux/libsomelib.so: undefined reference to `__isoc99_sscanf#GLIBC_2.7'
Contents of fix.txt are
GLIBC_2.7 {
global: *;
local: *;
};
Similar query was answered below here doesnt help. I want to know if anyone else have encountered similar error and resolved it.
My GCC version
-bash-3.2$ g++ --version
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
Finally the link in the question help with slight modification from other answers. Here is my fix.
I created a new cpp file with below contents
#include <iostream>
#include <stdarg.h>
__asm__(".symver __isoc99_sscanf,__isoc99_sscanf#GLIBC_2.7");
#ifdef __cplusplus
extern "C" {
#endif
int __isoc99_sscanf(const char *a, const char *b, va_list args)
{
int i;
va_list ap;
va_copy(ap,args);
i=sscanf(a,b,ap);
va_end(ap);
return i;
}
#ifdef __cplusplus
}
#endif
Compiled it to get the object file and used it along with fix.txt mentioned in the question.
However, I would like to inform that since my third party library was compiled on an higher version. I am getting ELF file OS ABI invalid when I run my binary.
There solution from some other answer which suggests to use patchelf and modify intert section doesnt help as shared files mostly dont have that section.
I also tried to compile glibc2.7 and build my binary using
-Wl,--dynamic-linker
-Wl,--rpath
flags pointing to glibc2.7 . Still in vain.
I am running fedora 23 and just compiled and installed casadi 2.4.1 (however, I do not think that this is casadi specific).
I am trying to compile and run a simple test program:
#include <iostream>
#include <casadi/casadi.hpp>
using namespace casadi;
int main () {
const SX m(42);
const SX n(23);
const SX x = m + n ;
std::cout << x << std::endl;
}
It works fine with gcc:
$ g++ test.cpp -std=c++11 -I$HOME/local/include -L$HOME/local/lib -lcasadi && ./a.out
SX(65)
But using clang, I get a linker error:
$ clang++ test.cpp -std=c++11 -I$HOME/local/include -L$HOME/local/lib -lcasadi && ./a.out
/tmp/test-cde41f.o: In function `casadi::GenericMatrix<casadi::Matrix<casadi::SXElement> >::dimString() const':
test.cpp:(.text._ZNK6casadi13GenericMatrixINS_6MatrixINS_9SXElementEEEE9dimStringEv[_ZNK6casadi13GenericMatrixINS_6MatrixINS_9SXElementEEEE9dimStringEv]+0x2b): undefined reference to `casadi::Sparsity::dimString() const'
/tmp/test-cde41f.o: In function `void casadi::Sparsity::set<casadi::SXElement>(casadi::SXElement*, casadi::SXElement const*, casadi::Sparsity const&) const':
test.cpp:(.text._ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_[_ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_]+0x6f0): undefined reference to `casadi::Sparsity::dimString() const'
test.cpp:(.text._ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_[_ZNK6casadi8Sparsity3setINS_9SXElementEEEvPT_PKS3_RKS0_]+0x743): undefined reference to `casadi::Sparsity::dimString() const'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I am pretty confident that the symbol is defined in the library. However, I fail to understand what clang is missing here. Is there some special c++11 ABI flag that I need to pass to the linker or something like that?
I would suspect version skew. Unless you do something special, clang uses some gcc stdc++ library, for which it searches. That was the case the last time I used clang for much. They may use their own std c++ library now. But if casadi was compiled with one version of gcc and you used clang which uses the std c++ library for another version of gcc, you can see linker errors like this.
You may learn something if you run clang -V to get version information. Also, gcc -v to get gcc version information, and verify that the version of gcc clang wants is the same as the version with which you are compiling.
How can I cross compile on Linux for Windows with code that uses C++11 features? So far I've attempted the following:
#include <stdio.h>
class foo
{
public:
const char* getstr() { return "hello world"; }
};
int main()
{
printf("Hello, World!\n");
foo f;
f.getstr();
auto q = f.getstr();
return 0;
}
This fails to build with:
i586-mingw32msvc-g++ cpp11_test.cpp
cpp11_test.cpp: In function ‘int main()’:
cpp11_test.cpp:15: error: ISO C++ forbids declaration of ‘q’ with no type
cpp11_test.cpp:15: error: invalid conversion from ‘const char*’ to ‘int’
No problem I thought, I just need the -std=c++11 option:
i586-mingw32msvc-g++ cpp11_test.cpp -std=c++11
cc1plus: error: unrecognized command line option "-std=c++11"
Still no luck, --version output is:
i586-mingw32msvc-g++ --version
i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2)
Copyright (C) 2007 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.
Is there another option to make this work? Or a new version? How would I get a new version if its not in the package manager, would I have to build a newer compiler from source using the host OS'es compiler?
Compiling this code
int main(int argc, char **argv)
{
int xor = 0;
}
via
g++ main.cpp
results in:
internal compiler error: Segmentation fault
with
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659).
Renaming the variable removes the error.
Question: Is gcc from Apple crap?
Any time your compiler segfaults, it's a bug. Your already reduced test case is a perfect candidate to be reported to GCC.
and_eq, bitand, bitor, compl, not, not_eq, or, or_eq, xor and xor_eq are keywords which are enabled with -ansi or -foperator-names
you have one of those switches enabled?
check also out: this