I am trying to build a c++ library of mine (which is dependent on facebook/folly) with gcc7. Some important points to note
Previously I was using gcc 4.8 to build this library
Since there is ABI incompatibility introduced in gcc 5.2 - I built folly from source (and all other dependent libraries like glog etc.) with gcc 7 - and I am using the updated libraries and shared objects.
My library uses openssl 1.1 (even previously when it was being built with gcc 4.8), where as folly (the version of folly that I am using) uses openssl 1.0.2
Even with the openssl version incompatibility the build of my library would go through fine with gcc 4.8 with the following warning
/usr/bin/ld: warning: libssl.so.10, needed by /home/<username>/folly/folly/1000.37.2.1/lib/libfolly.so, may conflict with libssl.so.1.1
I get the exact same warning with gcc 7 as well, but my build now fails with the following error
/usr/bin/ld: /home/<username>/folly/folly/1000.37.2.1/lib/libfolly.a(SSLSessionCacheManager.o): undefined reference to symbol 'SSL_CTX_get_ex_new_index##libssl.so.10'
/usr/lib64/libssl.so.10: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have tried researching this problem in regards to DSO missing from command line - but the solutions mentioned in other questions doesn't seem to be my case.
There are 3 questions that I am seeking to answer here
Can openssl version incompatibility be the reason for the build failure?
Why would the build succeed in gcc 4.8 but fail on gcc 7?
Is there an way to solve this without updating openssl version in folly (I will have to pull in a lot of changes for that - which will require code changes from my side). My library only uses openssl/md5.h
Related
What are additional configurations required in compilations and linking to successfully compile the c++98 codes using C++11/gnu+11 standard?
Existing gcc version is g++ (GCC) 4.8.5 20150623 on RHEL7 OS.
In order to use C++11 standard on the existing code written in C++98, flag -std=c++11 was added along with -D_GLIBCXX_USE_CXX11_ABI=0.
While compiling existing code, the following error is still thrown:
undefined reference to `__cxa_throw_bad_array_new_length'
collect2: error: ld returned 1 exit status
Please, help on this issue.
The post program linking fails when using custom built gcc helped me resolve the issue.
It was due to linking of the object file with different version of the system libraries.
The following packages were installed from repositories on CentOS 7.6:
clang-3.4.2-9.el7.x86_64
libcxx-3.8.0-3.el7.x86_64
libcxx-devel-3.8.0-3.el7.x86_64
Trying to build a simple C++ program:
clang++ -std=c++11 -stdlib=libc++ junk.cpp
This results in a bunch of linker errors, an example is:
/bin/../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc++.so: undefined reference to `__cxa_throw'
AFAIK, this seems to be a problem of missing C++ ABI library, but I can't figure out how to install one that would provide the needed symbols. I could probably build one from source, but would like to stick with what's available from trustworthy repositories.
Any ideas on how to fix this?
I can build the program just fine if -stdlib=libc++ is omitted, in which case libstdc++ is used.
Try passing -lc++abi manually. This problem is fixed in modern installations, but the Linux packages aren't modern. Consider using apt.llvm.org
Installing MinGW-w64 5.1 I find -fsanitize=address is available. It compiles fine, and when it starts linking I get thousands of:
undefined reference to '__asan_report_load1'
undefined reference to '__asan_report_load4'
I googled and found libasan referenced various places, but also comments that when you include -fsanitize=address it automatically includes that library for linking. I searched the MinGW-w64 5.1 install dirctory for "asan" and it was not found anywhere.
What do I need to add on to use address sanitizing features in MinGW-w64? Thank you.
I've looked quickly into release notes for 4.8, 4.9 and 5.1 - ASAN is not available for Windows
I am using g++ 4.1.2 and Boost 1.53 on Red Hat Linux rel 5.5. There is an issue during the linking process which is unclear to me. I get the error msg:
/usr/local/boost_1_53_0/stage/lib/libboost_thread.so:
undefined reference to `std::bad_exception::what() const#GLIBCXX_3.4.9'
/usr/local/boost_1_53_0/stage/lib/libboost_thread.so:
undefined reference to `std::bad_alloc::what() const#GLIBCXX_3.4.9'
collect2: ld returned 1 exit status
There seems to be a problem related to the libstdc++.so file version I'm linking with. If I alternate hiding and revealing this file I can get my program to link. However, I would like to be able to 'make' in one step as I did before I introduced the Boost libraries and concurrent threading.
Please help shed some light on this issue if you have any insight.
Please try to install via yum.
yum install boost
You will not encouter such issues.
Try to include rpmforge and epel yum repositories.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning shows that GLIBCXX_3.4.9 is the symbol version used by the libstdc++.so from GCC 4.2.0, so if the Boost library wants that version then it means it was compiled with GCC 4.2.x
That means you can't use the library with a program linked by GCC 4.1.2, you need to link with GCC 4.2.0 or later
libstdc++.so is backward compatible but not forwards compatible, so you can compile a program with one version and link it to a newer version, but you can't compile with a newer version and link to an older version.
I'm trying to port a project of mine on Mac OS-X.
As I developed my project using C++0X I needed a more recent version of GCC than the one provided with Xcode (even Xcode4), so I compiled GCC 4.6 on my Snow Leopards Mac.
My project does compile fine and it does start too on the computer I compiled it (OS-X 10.6.7) but when I transfer it to my MacBook (OS-X 10.5.8) it doesn't works.
It returns the following errors:
dyld: lazy symbol binding failed:
Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
dyld: Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
I understand that the program needs the libstdc++.6.dylib of the GCC 4.6.0 as this file contains the C++0x functions (despite the fact that my current test doesn't use any C++0x function) instead of the standard libstdc++.6.dylib usually included in the OS-X system.
So I tried the following:
to specify -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 in order to ensure backward compatibility with OS-X 10.5. But the error remains the same.
to verify the libstdc++.6.dylib path using otool -L and changing the shared library path using install_name_tool -change /opt/local/lib/gcc46/libstdc++.6.dylib #executable_path/../Libraries/libstdc++.6.dylib OgreApp (with a copy of the gcc 4.6.0 libstdc++.6.dylib in the Libraries folder) as suggested as answer of my previous question. But the error remains the same.
to statically link libstdc++ and libgcc using -static-libgcc - static-libstdc++. But it still returns the same error.
As my program use the Ogre framework, I applied the above manipulations to the Ogre executable embedded in the Ogre.framework too, but it doesn't change anything.
Does anyone can explain me how I'm supposed to deploy an application created with a non standard libstdc++ on another Mac computer installed with an older version (I guess the problem is the same with a computer running Snow Leopard as the program use the GCC 4.6.0 libstdc++) ?
Mac OS X 10.5 does not include a compatible copy of the GCC standard library. If you want your code to run on Leopard, you'll have to either modify it to compile under an older version of GCC, or you'll have to... well, really that's your only option.