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.
Related
Today all our infrastructure is based on python 2.7.2 and we want to use it on Windows10 ARM64 machine as well. But in the link below, you can see that the ARM64 compiler is included in VS2017 and not in previous versions.
So no chance to compile python 2.7 for windows10 ARM64?
Did someone try that?
What are your suggestions?
https://wiki.python.org/moin/WindowsCompilers
I've just ran into this, I know it's a little late but never late than never.
I'm just in the process of building Python 2.7 for Windows aarch64. It seems to work with some minor patches (mainly required to get it to compile with MSVC2017, since 2.7 is usually compiled on the ancient MSVC2008, which doesn't have a native aarch64 compiler).
The interpreter seems to work just fine but I still need to finish building all the included modules before I can say it's ready. Right now I got around half of them running and I hope I can get the rest working soon. The biggest pain is going to be ctypes, I think I'll get it working eventually but issues are expected.
If this is still relevant please post a reply and I'll share it when I'm done building everything.
EDIT: Just finished, download Python 2.7 ARM64 and a bunch of other ARM64 open source programs and libraries from here -
https://mega.nz/#F!PclhDIRB!-yhBZ6UM7S596ijNU3dx0A
Interesting delema.
Trying to compile Qt program where Qt is build from source on 18.04 64-bit and run it on 14.04. The interesting part is trying to identify which libraries I need this time. The C++ ABI has changed.
Looking to see if anyone else has done this recently? Which libraries do I have to bring along? Yes, I know about ldd and readelf and have spent days trying this in various VMs. The problem is once you start bringing the C++ stuff over (because the ABI has changed yet again) you get to a point where your VM won't reboot.
Please don't suggest snappy, flatpak or one of those other new "container" solutions. Already wasted 3+ days on snappy. It's architecture specific and only supports building on 14.04 when it comes to Qt, at least the deployqt tool to make an AppImage does.
Did this years ago with this very program. Built a debian which would install on both 64-bit and 32-bit for every version from 12.04 to 15.04 including the short lived .10 and odd year versions.
I tried compiling QT with C++11 standard, but, it will no longer compile with that standard.
The incompatible ABI is the real killer.
It is more than one program so the hack of a shell script using LD_LIBRARY_PATH would bring considerable difficulty.
Appreciate insights.
Thank you.
Please always develop applications on the oldest distribution you still want your application to run on. For example, if you want your application to run on all currently still-supported versions of Ubuntu, then develop your application on Ubuntu 14.04 and do not install any newer compilers or libraries than what it comes with.
This is how "backward compatibility" works.
I am building a build environment for some cross compiled embedded sw, it is quite old, so when compiling in Ubuntu 16.04, I get a conflict, that is "redefinition of struct timeval". I was comparing time.h from old systems, I figured out timeval structure was not yet in the old libc, is it possible for me to downgrade libc?
unfortunately, no, you cannot downgrade the C library in your distro. all the other programs in your system were compiled against that new version, so trying to downgrade it will break everything (literally everything --
like basic programs of ls and mv and such).
you can either fix your old source project, or find an old release of a distro (like Ubuntu) and install it in a VM.
This question already has answers here:
Deploying Yesod to Heroku, can't build statically
(4 answers)
Closed 6 years ago.
I built an exec on C++, however when I deploy it to the deployment machine I find errors like :`
/lib64/libc.so.6: version GLIBC_2.14 not found
/usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.14 not found
/usr/lib64/libstdc++.so.6: version CXXABI_1.3.5 not found
This turns out because the deployment machine is rhel based system with older libc(2.12)/libstdc++(3.4.13) while my machine is ubuntu with far recent kernel and libraries. Unfortunately I cannot upgrade the deployment system.
I tried some of the usual ways to handle this like static linking (libc fails) and copying my library versions to the cluster (and run with LD_PRELOAD and -Wl,--rpath options) , but it doesn't work.I also installed an older version of gcc on my machine, but that also doesn't work.
Is there some way I can get this to work (perhaps making object code on my local machine,and linking it on the other machine). Or is there a way to compile the code on the deployment machine without copying source to it.
Could this work with getting a copy of system libraries from deployment machine and try to get gcc to link with them? (any issues with that, and how to do that correctly)
Related to Compile with older libc (version `GLIBC_2.14' not found) and Deploying Yesod to Heroku, can't build statically
and Build and run C++ code on different version of Linux and glibc
I am aware of one way to do this via VM , but I want to avoid it if possible.(HT Mat)
Compile you application with -static-libstdc++ option.
This question already has answers here:
Deploying Yesod to Heroku, can't build statically
(4 answers)
Closed 6 years ago.
I am getting this error while I am running the code in GLIBC version 2.12, which was compiled in 2.19.What is the standard solution to this problem, so that the code can run in all versions.Upgrading the target machine to 2.19 is not an option because this software is supposed to run in at least 5000 machines.Dow grading the development machine to 2.12 is also not a proper solution. Because 2.19 is just one example. The 5000 target machines can have any version.What is the standard solution for this ? Anyway of static compilation ? I mean bundling the entire GLIBC with the code .
The easiest solution is to simply create a "build server" which you use for your production builds, and keep this server on the oldest version of everything you need to support, including glibc.
This can be done using a VM inside your development server if you don't want to use a physical machine.
Bbinaries compiled against glibc should be forward-compatible; the binaries you compiled against glibc 2.19 were using an API version that appeared in 2.14. If instead you compile against 2.12 it should work at runtime with Glibc 2.19 as well.
In Python-land, they're now offering prebuilt Linux C extensions that are built on Centos 5.11 Docker images; The PEP 0513 explains details. They seems to work pretty well there. Centos 5.11 seems to have glibc 2.5; Centos 6 has glibc 2.12. I am using these prebuilt .sos on Ubuntu 14.04 and 15.10 myself without any problems.
There is also a very hackish solution, by placing the required libc.so (2.19) file in a specific directory (just copy it over), creating a runner script, where you set the LD_LIBRARY_PATH to have the specific directory and then you run the executable. The system should pick up the libc.so from the specific directory before the one provided by the system, so it should work.