I am compiling a product under Debian 7.5. During compiling using makefile, I incur in an error :
undefined reference to `memcpy#GLIBC_2.14'
In my system it is installed libc6_2.13.
I am aware that that component cannot be upgraded painlessly, but I'd like to understand if I can have the 2.14 concurrent with it just for this task, then I won't need it anymore. I have looked for a solution since yesterday, but i am wandering.
I need to understand if it is possible or not to use GLIBC 2.14 on my linux version just for a one shot compiling, without damaging it, or if I can
Notes: I cannot change system distro.
Related
We have some servers with ARM CPU and will test some SW applications. With Ubuntu system, there is no big problem because the kernel and the SW are quite up-to-date. But with CentOS system, some tools and libs are quite old on ARM. For example, the GCC compiler is still 4.8.5 and some features couldn't be supported.
On X86_64, this is not a problem, because there are SCL and other sources with stable packages.
On ARM, now I find to choices, one is from RH and the other is from Linaro.
https://releases.linaro.org/components/toolchain/binaries/latest/
The Linaro project provide some source of GCC5, 6 and 7. We could build and run on the system. Ubuntu ARM version is using the GCC from Linaro right now. But on the release notes, it just mentions Ubuntu but no CentOS support. (Even this could be done on CentOS)
https://buildlogs.centos.org/centos/7/sclo/aarch64/rh/
The RH also provide the GCC for aarch64 as on the X86_64 computer/server. But now it is still in the test repository but not the official update sources. And only GCC6 and 7 are provided.
So any suggestion? Should I use the test version from centos.org or the source code from Linaro.
Many thanks in advance
Depending on the ARM CPU Servers are you targetting, the vendor may also provide you with the OS and packages/repo which is recommended to be used.
Linaro might be a better pick than the test repo (expected to be more stable) in the case that you are doing some functional/performance testing of SW applications. Even though centos7.4 is not stated as officially supported platforms, its worth a try. Its likely that the Linaro GCC toolchain will just work on the OS of your choice.
You may also download the latest GCC from the public mirrors and try, say one of the GCC 7 releases (At the moment, the latest is gcc 7.3.0 https://gcc.gnu.org/gcc-7/). Aarch64/Aarch32 are supported targets.
Whatever you chose, ARM CPU server ecosystem is actively evolving as these chips are just hitting the market. You might want to check which of the above (Linaro/GCC/RH) is being actively contributed to in the area of the target platform of your choice.
Background Info:
Linux OS: Stripped down, minimalistic and very customized (no apt-get, yum, etc)
Linux Kernel: 2.6.19.1
Current glibc version: 2.3.6
Target glibc version: 2.6.1
Issue:
Attempting to install an ipk package provided by 3rd party which has a dependency on a glibc version >= 2.6 (current version is 2.3.6)
The 3rd party provided a different ipk package to upgrade glibc to 2.6.1. After executing the install of the package, all other applications that depend upon glibc report "libc.so.6: cannot handle TLS data"
Is anyone familiar with upgrading glibc on a customized Linux OS without using any sort of package manager for support?
My understanding is that glibc should be backwards compatible and upgrading it shouldn't cause issues with applications that had previously been working. Is this assumption incorrect?
I can post more information as it is requested. Any and all help is greatly appreciated, thank you in advance.
My understanding is that glibc should be backwards compatible and upgrading it shouldn't cause issues with applications that had previously been working.
That is correct.
Your issue is most likely the result of mismatch between ld-linux and libc.so.6 -- they must come from the same build, of bad things will happen (GLIBC actually consists of many libraries, and they all must match).
It's possible that your 3rd-party provided glibc package is mis-configured and replaced one, but not the other. Possibly it installed libc.so.6 into /usr/local/lib instead of whatever location is appropriate for your OS.
So find all files that "belong" to GLIBC before the installation of 3rd-party update, and verify that every one of them is replaced by it.
It is also possible, though less likely, that the 3rd party package is simply broken, or configured without TLS support.
If you link an app against GLIBC with TLS support, then upgrade GLIBC to one configured without TLS support, the applications will break. That is expected and "normal" (configuring GLIBC without TLS support is simply not a good idea).
Trying to use the nsocr (an OCR based application) shared library namely libjnsocr.so & it works successfully on a Ubuntu system. When running the same on a RHEL 5.1 box, I get an error as
ERROR_DLLNOTLOADED 0x70010002 or Cannot find or load the "NSOCR.dll" file.
One of the issues that might be the source is that Ubuntu runs on a recent version of Linux kernel i.e. 4.2 whereas the server where I am running the program is on kernel version 2.6 which is very old.
Please let me know if there is some way to make this file compatible for the older kernel. Appreciate any other inputs.
When running the same on a RHEL 5.1 box, I get an error as
... Would probably work if you used like Ubuntu 7.04 to create the
libraries / the application.
Say libjnsocr.so depends on e.g. libc6 version 2.11 or later. Redhat 5 has glibc-2.5 ( = libc6-2.5 ) : No chance that any contemporary application can work.
We build a shared library which depends on libsdl-gfx.
On Ubuntu 12.04 through 14.10, libSDL_gfx.so.13 is linked; On Ubuntu 15.04 and 15.10 libSDL_gfx is updated to libSDL_gfx.so.15.
In order to make it work, we need to build another version of our shared library which depends on libSDL_gfx.so.15.
So the question is what is the correct way for this case? Is it possible to just build my library once which can be used on both Ubuntu 12 and Ubuntu 15? Thanks.
LJ
So the question is what is the correct way for this case?
What you are already doing: build two versions of your library.
Is it possible to just build my library once which can be used on both Ubuntu 12 and Ubuntu 15?
No. Assuming libSDL_gfx.so developers are competent, there is a reason they changed the external version of the library: an ABI change. If you tried to use your library with ABI-incompatible version of libSDL_gfx, you would get a crash (or worse -- subtle memory corruption). Read about external library versioning here.
Good day! I've got a problem with linkage on Linux using gcc. For example, I've compiled project on one machine and linked it with libGLEW. When I'm trying to run it on another machine - it can't find libGLEW, because first machine has libGLEW.so.1.7 and second has libGLEW.so.1.10.
ldd shows me, that it dependent on 'libGLEW.so.1.7'.
after creating symlink 'libGLEW.so.1.7 => libGLEW.so.1.10' everything works fine, but is there a way, to store 'libGLEW.so' as dependency instead of 'libGLEW.so.1.7'?
What makes you sure the function interface of GLEW doesn't have changed?
Or even the content of version 1.1 to 1.7 is still the same?
If it is build with 1.7, it also depends on 1.7.
So you shouldn't run it on another version of GLEW, except the api documentation of GLEW tells you that this cross versioning is possible for some reason (But I couldn't imagine that).
Otherwise also build it with GLEW 1.1 in addition
(because as if all features you use from 1.7 are also supported by 1.1 and for some reason you have to support both versions), so to serve different versions fo your programm for different versions of GLEW would be the best and valid way.
If that is not the case make it for the user as requirement to be on Glew version 1.7 or higher.
But there is no safe way of working around to archive what you want.
And there is not a gcc or any compiler command for that at all.