libstdc++

Now that multiple C++ standard libraries can exist on Mac OS X, it now looks like quite a chaotic situation. According to https://stackoverflow.com/a/8457799/1772681 , mixing libstdc++ and libc++ will result in link error, which catches such dangerous situation and is a good thing. On the other hand, There are still 2 situations need more investigation, and I have created a few test cases for this in github gist ( https://gist.github.com/manphiz/7195515 ). It confirms that mixing dynamic libraries that link to libstdc++ (either from system or vanilla GNU GCC) and libc++ (system) will result in

I'm trying to use the std::shared_ptr in clang++(clang version 3.1 (trunk 143100)) using libstdc++(4.6.1). I have a little demo program: #include <memory> int main() { std::shared_ptr<int> some(new int); std::shared_ptr<int> other(some); return 0; } which can be build using: clang++ -std=c++0x -o main main.cpp and gives the following error output: main.cpp:6:23: error: call to deleted constructor of 'std::shared_ptr<int>' std::shared_ptr<int> other(some); ^ ~~~~ /usr/include/c++/4.6/bits/shared_ptr.h:93:11: note: function has been explicitly marked deleted here class shared_ptr : public _

When I use GCC, I can build program on my Ubuntu 15.04 using this: -static-libgcc -static-libstdc++ And compiled binary can run on "stock" Ubuntu 14.04 without any external packages, only standard updates. Is there possibility do build with this static linking to library with clang ? Most common answers: using test ubuntu rep ( ppa:ubuntu-toolchain-r/test ) update server recompile on target server don't use GCC is not suitable for me. Just can I do this with clang for run it on Ubuntu 14.04.3 LTS? clang is compatible with gcc on this matter. Basically for hello-world program that uses iostream

This question already has an answer here: Segfaults in malloc() and malloc_consolidate() 2 answers My program goes in segmentation faults, and I cannot find the cause. The worst part is, the function in question does not always lead to segfault. GDB confirms the bug and yields this backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb7da6d6e in malloc_consolidate (av=<value optimized out>) at malloc.c:5169 5169 malloc.c: No such file or directory. in malloc.c (gdb) bt #0 0xb7da6d6e in malloc_consolidate (av=<value optimized out>) at malloc.c:5169 #1 0xb7da9035 in _int_malloc (av=

After reading about the problem of passing empty std::string objects between DLLs and EXEs, I am concerned about the configure options used to build my gcc / libstdc++. More specific I want to know if --enable-fully-dynamic-string was used during ./configure . I'm using MinGW 4.4.0 on Windows XP. Does anybody know the configuration used to build this release? Is there a general way to find this information for any installation of GNU gcc? The gcc manual gives me no hint on this topic. Thanks for your input! gcc -v prints out the configuration options among other stuff: $ gcc -v Using built-in

I would like to compile boost for Mac OS X 10.9, with stdlibc++. I run the following command: ./b2 threading=multi link=static runtime-link=static cxxflags="-stdlib=libstdc++" linkflags="-stdlib=libstdc++" The build completes successfully; however, my application build fails at linkage time, when it can't find symbols suck as std::__1::locale::use_facet, std::__1::basic_string etc. The pertinent detail there is the __1, I believe. My question is, how do I compile boost for OSX 64b platforms with stdlibc++? More info: I have noticed the following logs during compilation: /Applications/Xcode.app

Is there anything from c++11 that I can use and expect compiled binaries to run on older systems? How can I tell which parts of c++11 are a part of the libstdc++.so and what actually gets compiled into the binary? Maybe I don't fully understand how such things work. Does c++11 break ABI compliance with older libraries? An example for clarity: Say I compile a program that uses auto and the new range based for loop. These things seem like they should work on systems with old c++ runtimes because they break down into c++ that would be valid on those machines. However, using something like regex