I am trying to build open embedded project. But it shows some error like
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: GLIBCXX_3.4.26 not found
How can i install GLIBCXX_3.4.26 in Ubuntu 16.04 ?
I believe the object you are trying to use was compiled with a fairly recent version of GCC 9 with this bug fixed. This GCC version has not yet been released.
You need to recompile it with the Ubuntu system compiler, or ask the Ubuntu compiler people to backport this fix into the Ubuntu 16.04 system compiler (which seems fairly unlikely to happen at this point).
I solved the problem by 2 steps:
1 Install a Anaconda3
2 Copy the file libstdc++.so.6.0.26 to path '/usr/lib/x86_64-linux-gnu', then create a soft link.
I worte the detail commands here.
Related
Error: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /root/workspace/backend/node_modules/uWebSockets.js/uws_linux_x64_72.node)
Latest glibc version for CentOS 7 is 2.17.
I know that latest version for CentOS 8 is 2.30 but I can't upgrade, because my VDS depends on host's machine kernel (which is very old).
Is there any way to run/compile it with glibc-2.17 or update glibc?
EDIT:
My kernel version is 2.6.32-042stab141.3.
I can build it and install to /opt/glibc-2.18 without errors, but when I trying to use this I see Segmentation fault error.
P.S. I builded it successfully on Fedora 23 with same OpenVZ kernel.
I have built a custom binary (and tutorial) that will solve your exact problem.
Read it here: https://github.com/dominicklee/uWebSockets.js-for-Centos7
Is there any way to run/compile it with glibc-2.17
Yes: just do it (download source, build on your target machine, profit).
or update glibc?
You didn't say what your "very old kernel" is, but if GLIBC-2.18 supports it, then yes, you can update GLIBC.
However, any mistake you make in the process may make your system un-bootable. See this answer.
I can't get a cross compiled build running on my Raspberry Pi 1 B+. The error I keep getting is:
ImportError: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version 'CXXABI_1.3.11'
not found. I tried multiple compilers with different settings but I keep getting the same error. Also changing the LD_LIBRARY_PATH to the location of libstdc++ on my Pi didn't work. Today I got a sort of breakthrough finding out that the make process outputs "will change in GCC 7.1" after an argument. I'm not a hundred percent sure that this is what cause the error, but GCC 7.1 comes with version 1.3.11 of CXXABI, so I suspect it to be the cause. Is there anybody that knows how to stop this from happening? I'm building on a VM with Ubuntu 17.10. I'm building using sh autogen.sh; ./configure --host=arm-linux-gnueabihf; make -j8
Thanks
Edit: Found the solution myself, it was: export CXX=/path/to/toolchain/arm-linux-gnueabihf-g++
Your cross-GCC comes with a version of libstdc++.so which is not compatible with the one installed on your system. You can either run compiled program with modified LD_LIBRARY_PATH (or -Wl,-rpath), pointing to directory with cross-compiler's libstdc++.so, or downgrade your cross-compiler to match your distro.
I am receiving the following error when I try to compile a very basic C++ program.
$ g++ -fuse-linker-plugin test.cpp
g++: fatal error: -fuse-linker-plugin, but cyglto_plugin.dll not found
compilation terminated.
Code
int main() {
return 0;
}
This is using G++ installed straight out of a fresh Cygwin installation.
If I search for the file there, it does exist and is located at:
/usr/libexec/gcc/x86_64-pc-cygwin/4.8.2/cyglto_plugin.dll
How do I make Cygwin 64 look at this correctly?
I guess you only checked the gcc-g++ package at installation. Note that the version is 4.8.1-3 BUT on the next page you can see a lot of dependencies being installed, for example libgcc with version 4.8.2.
That mix of 4.8.1 and 4.8.2 seems to be the problem.
In the installer, copy all dependencies into an editor, search for 4.8.2 to find the problematic packages, go back in the installer and click those packages until 4.8.1-3 will be installed.
Double check you're not installing the latest version of those packages.
More recently using apt-cyg, g++ 4.9.2 was installed but gcc-core 4.8.2 remained.
Resolved by:
apt-cyg remove gcc-g++
apt-cyg remove gcc-core
apt-cyg install gcc-g++
Two version of gcc was causing proble, check folder /usr/libexec/gcc/x86_64-pc-cygwin/ there would be two version of gcc.
To solve remove one.
The above answer worked for me, but I got caught by the installer automatically upgrading packages back to 4.8.2. So, I initially thought this didn't work; it actually did. You just need to be aware of that when using the installer to add packages later, it may try to upgrade back to 4.8.2 again and break things.
There is the option to turn off LTO with -fno-use-linker-plugin, but that doesn't do me any good becuase CPAN is what is launching g++. It might serve as a workaround.
(I know this isn't much of an answer, but I was unable to comment)
I am starting with IGPROF for memory profiling--
i installed it and done all the steps defined in - http://igprof.sourceforge.net/install.html
but when i am running:
c++ -o vvvi-build-and-copy vvvi-build-and-copy.cc -ldl -lpthread
i am getting error-
c++: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by c++)
i google it but not getting what should i do?? i am using ubuntu right now.
Can you help me ?? plz tell me if you need any other info
Thanks in advance....
It usually means that you are using library compiled by newer compiler (gcc) than you are currently running. You need to recompile library with your current compiler or change to newer compiler.
You do not say what version of Ubuntu. Anyway, the problem is caused by a glibc version mismatch between your C++ and the version installed in Ubuntu.
Run the command
/lib/libc.so.6
to get information on your system's glibc, to confirm. You will see something which is not "version 2.11" as your installed C++ requires.
Your situation may occur if you did an incomplete update of the distribution (i.e., glibc is older than C++ expects, because you forced an update to C++ but left glibc behind).
The best solution should be to do an "apt-get upgrade" of the "old" packages ("apt-get upgrade glibc"), or even update the whole distribution.
Note: this probably has nothing to do with igprof installation, which is unlikely to have modified C++, much less glibc.
I am trying to deploy my application from development environment to users' computer, but I have some issues.
First, I compile and run it on my development computer (higher version Ubuntu11.04):
Ubuntu11.04$ make
Ubuntu11.04$ ./MyApp
Program runs okay.
Then I copied the binaries MyApp to two lower-version machines (users' computer):
Ubuntu10.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
Ubuntu8.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./MyApp)
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
However, if I compile the source code on Ubuntu10.04, and run it:
Ubuntu10.04$ make
Ubuntu10.04$ ./MyApp
Program runs okay.
What should I do with this? When I compile it in development environment, how can I set the version number of the used library? I'm not directly using GLIBCXX, I think it's being used implicitly somewhere in my project.
Thx a million.
Peter
Did you see Link with an older version of libstdc++
I have never installed an older version of g++, but I have included a libstdc++.so in my release and that has worked for me. Best solution I have seen is get your development stuff to work on the oldest possible system. We compile some stuff on Red Hat 9 and it work on everything, but it can be any major issue building on old machines as you say.
You have built on version N, and tried to deploy on version M, M<N. You will need to get the deployment computer upgraded, or learn the procedure to compile and link targeting an older version. Since the problem lives in libstdc++, I'm afraid that my advice is to downgrade your entire dev system or upgrade the target, libstdc++ is not easy to deal with. Another answer here has someone's recipe.
Keep in mind that the Ubuntu/Debian community is optimized for open source. From their point of view, the solution to this is for you to distribute source code with the auto* tools, and let the user built it for him or her-self. They don't stay up late making this easy for you.
Here in the evil world of closed source, we keep around VMs running all sorts of old linux distros just so that we can build a single binary that runs in many places.