I have an example code:
#include <quadmath.h>
int main()
{
__float128 foo=123;
cosq(foo);
return 0;
}
I tried to compile it with the following commands:
g++ f128.cpp -lquadmath
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0 /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
All these commands produce one and the same error:
f128.cpp:(.text+0x1b): undefined reference to `cosq(__float128)'
I also tried to declare cosq as follows, without inluding quadmath.h. Declarations of such style are used in C++ interface to fortran subroutines in other programs, and they work well.
extern "C" __float128 cosq_(__float128 *op);
extern "C" __float128 cosq_(__float128 op);
extern "C" __float128 cosq(__float128 *op);
...and so on...
Result was the same.
Then I tried to use cosq in Fortran:
PROGRAM test
REAL*16 foo
REAL*16 res
foo=1;
res=cos(foo)
PRINT *,res
END
This program compiles and executes well (prints the answer with lots of digits), so cosq works in it. This program was compiled with no options: gfortran f128.f90.
OS is OpenSUSE 12.1, gcc version is 4.6.2. *.h, *.a and *.so files mentioned are provided by gcc46-fortran and libquadmath46 packages.
What is the proper way to use cosq and other quadmath functions in C++? I wouldn't like to write Fortran wrappers for them.
First, according to Nikos C. advise, I boot up OpenSUSE 12.2 liveCD (which has gcc 4.7.1) on another machine, but got the same error.
Then I posted this question to OpenSUSE forums.
Martin_helm's answer shows that the problem is distro-independent and the solution is trivial:
extern "C" {
#include <quadmath.h>
}
This works fine on all my machines. Program can be compiled with g++ prog.cpp -lquadmath.
Related
with _GLIBCXX_USE_CXX11_ABI=0
std::function of GCC-4 is different of GCC-5 and follwing versions.
The following code show you the fact:
==> lib.cc <==
#include <functional>
std::function<int(const void*p)> holder;
int run_holder(const void *p)
{
return holder(p);
}
==> main.cc <==
#include <stdio.h>
#include <functional>
extern int run_holder(const void*p);
extern std::function<int(const void*p)> holder;
int foo(const void* p)
{
printf("p=%p\n", p);
return 0;
}
int main()
{
holder = foo;
foo((void*)0x12345678);
holder((void*)0x12345678);
run_holder((void*)0x12345678);
}
==> make.sh <==
#!/bin/bash
GCC4=/usr/bin/g++
GCCN="scl enable devtoolset-5 -- g++"
$GCC4 -std=c++11 -c -g lib.cc -shared -o libfoo.so &&
$GCCN -std=c++11 -L. -lfoo -g main.cc -o a.out &&
LD_LIBRARY_PATH=. ./a.out
expected result, something like:
p=0x12345678
p=0x12345678
p=0x12345678
actual result:
p=0x12345678
./make.sh: line 6: 973 Segmentation fault LD_LIBRARY_PATH=. ./a.out
The reason is the implementation of std::function changes without document.
gcc4: /usr/include/c++/4.8.2/functional:2430
typedef _Res (*_Invoker_type)(const _Any_data&, _ArgTypes...);
gcc5: /opt/rh/devtoolset-4/root/usr/include/c++/5.3.1/functional:2226
gcc8: /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/std_function.h:609
using _Invoker_type = _Res (*)(const _Any_data&, _ArgTypes&&...);
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8. There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8.
Correct. Neither Red Hat nor the GCC project has ever claimed that's possible, quite the opposite. C++11 support in GCC 4.x was incomplete and unstable, and subject to ABI changes and API changes. What you're trying to do was never supported.
I've explained this in more detail at https://stackoverflow.com/a/49119902/981959
The Developer Toolset documentation covers it too (emphasis mine):
"A compiler in C++11 or C++14 mode is only guaranteed to be compatible with another compiler in C++11 or C++14 mode if they are from the same release series (for example from Red Hat Developer Toolset 6.x).
...
"Using the C++14 language version is supported in Red Hat Developer Toolset when all C++ objects compiled with the respective flag have been built using Red Hat Developer Toolset 6 or later. Objects compiled by the system GCC in its default mode of C++98 are also compatible, but objects compiled with the system GCC in C++11 or C++14 mode are not compatible."
There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
We do not provide macros to control things that are unsupported and cannot work.
If you want to use C++11 with a mix of GCC versions you need to use a release that has stable, non-experimental support for C++11. So not GCC 4.x.
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
I have:
-cygwin 1.7.25 on windows 7/32bit
-g++ --version --> g++ (GCC) 4.8.2
-libstdc++.a --> gcc-g++-4.8.2-1
Tried to make a c++
Hello World:
#include <string>
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
compiling gives:
$ g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:10: error: ‘stoi’ is not a member of ‘std’
int i = std::stoi(s);
I searched for hours but I still could not find a solution. What's the issue here?
That's a bug, possibly an incomplete port of some library code to cygwin (it's a cplusplus11 feature) - some stuff has to be changed after all. Make sure to report it.
The solution is easy of course: #include <cstdlib> strtol(s.c_str(),0,10);
www.cplusplus.com/.../strtol
A similar mingw bug is mentioned also here
std::stoi doesn't exist in g++ 4.6.1 on MinGW
I have the same problem yesterday. "error: 'stoi' is not a member of 'std'."
First, I made sure c++11 was enabled. Then, I updated the g++ compiler to the newest version. After that, this error disappeared.
The compiler is not being taken seriously. On windows your best bet is to probably use visual studio, as it is always kept up to date . The bug here is that the macro defs are wrong to begin with. The problem starts from iomanip.h and iosbase . So they would have to changed all of there code. There are user made patches for this but I would not trust them at all, as they may contain even more bugs then the original copies. But it's up to you , I just stick with visual studio express edition.
stoi works correct only on mingw64 for me.
If you use Codeblocks, don't forget to check if your projects compiler is set to mingw64.
Well, I am working with -std=c++98, not -std=c++11 but I solved it with the following:
int i = std::atoi(input.c_str());
atoi() is waiting for c type null-terminated string, c_str() makes it null-terminated char*. To use atoi I also() added the following library:
#include <cstdlib>
my system is:
Ubuntu 22.04.1 LTS
I wrote a c++ program using boost library in Xcode. Here is my code. It is very simple.
#include <iostream>
#include </usr/local/include/boost/math/special_functions/beta.hpp>
using namespace std;
using namespace boost::math;
int main (int argc, char * const argv[])
{
double a = 100.0;
double b = 100000.0;
double x = 0.3;
double result = beta(a, b, x);
cout << result << endl;
return 0;
}
But when I tried to build it in the Xcode, there popped up a lot of errors related to the library linking stuff. I noticed that the compiler that Xcode was using was "System Default: gcc 4.2". And all other options are gcc or LLVM gcc (I have no idea what this is).
I later tried to compile the file simply using terminal. Weird thing happened. If I compile it with g++, without any extra flags, the compilation completed successfully and the the program could be ran normally; but if I compile it with gcc, there are pages of errors.
So, to sum it up, while using g++, everything is OK; while using gcc, everything is not OK. Since the Xcode is using gcc, the program could not be compiled using Xcode.
(And I kind of need to use the Xcode because this is just a test program, I actually have a much bigger project to handle and I depend on the debugger of Xcode.)
So my question is, WHAT THE HELL is the difference between gcc and g++? Or how can I change the compiler of Xcode to g++?
gcc is a C compiler.
g++ is a C++ compiler.
You're trying to compile C++, ergo, you need to use a c++ compiler.
Googling "Using XCode for c++" brings up lots of results, but this one seemed fairly straightforward and had pictures:
https://www.cs.drexel.edu/~mcs171/Wi07/extras/xCode_Instructions/index.html
The gcc command compiles C files (although you can use -libstdc++) to link C++ files as well but I don't recommend it.
The g++ command works for C++ files which is why it worked in your case.
For XCode you have to change the compiler from GCC to G++ for it to successfully work.
I have a mixture of c and c++ files compiling under g++. As explained in:
What is the difference between g++ and gcc?
The c files are being compiled as c++ with the g++ command line. Not huge problem but migrating over to gcc will allow th c files to compile as c files and the c++ file to compile as c++.
What -I includes or -L libraries do I need to add to the gcc command line, that the g++ command line is including by default?
You shouldn't need to add any includes or libraries beyond what you already have.
Whatch out for C functions being called from C++ code - you need to tell the C++ compiler those are C functions so the program is linked correctly and works.
The standard practice is to add the following directives to all your C headers being included in C++ files:
#ifdef __cplusplus
extern "C" {
#endif
... C header contents go here ...
#ifdef __cplusplus
}
#endif
More info here: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
You shouldn't need to add any. If it's using C++ it should automatically bring in C++ libraries.
If not, you'll want -lstdc++ (and if you're still getting undefined references, -lc for the libc). Don't forget -lm if you use math functions.
GCC can determine which language a file is in based on the file extension. However, GCC does not automatically link in run time support for any language other than C. In practice that means you can compile C++ programs using gcc instead of g++ but you'll need to add the -lstdc++ directive:
#include <iostream>
int main()
{
std::cout << "Hello world\n";
}
g++ hello.cc
gcc hello.cc -lstdc++
More accurately, you will need to specify -lstdc++ if you you use the standard library, exceptions, operator new, or RTTI. For instance, try compiling the following without -lstdc++:
int main()
{
try {
throw 1;
}
catch (int i)
{
return i;
}
}
Please note that STL containers (including std::strings) use operator new by default. Strictly speaking you should be able to use the algorithms (std::min, std::find_first_of, etc.) binders and a few other things in the standard library without -lstdc++ but for the most part you might as well include it (the linker will ignore any libraries that you don't actually link to).
Why not compile the c objects with gcc and the c++ with g++ and then when you link, link using the g++?