I'm wrote an application and I need to execute it on Gentoo,
but when I try run it, I get the following message:
/lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /usr/local/myapp/lib/myapplib.so.1)
the current GLIBC version in this gentoo is 2.3.2.
I can't update this glibc, because I don't have permission, so I need to 'downgrade'
my glibc to the same version (2.3.2) ... how can I do it?
tks,
The "/lib/libc.so.6: version `GLIBC_2.3.4' not found" problem comes from trying to run a binary compiled against a newer glibc on a system with an old version of glibc. Downgrading glibc is strongly discouraged for this reason.
Since you say you wrote the application, it seems to me that the simplest solution is to recompile the application on the system where you plan to run it.
I'm actually wrestling with the same issue, so maybe I have some information that can help.
In short, your binary was compiled to look for libc.so.6. GLIBC_2.3.4 is in libc.so.5. As far as I know, if you downgrade your glibc on your dev machine some of your other programs may not work properly (because they were compiled to look for the current version). Somehow CentOS/RHEL have a compat-glibc package that can live along side of a current glibc without causing this error. If your dev box uses CentOS/RHEL, install that package/recompile and you should be good to go. You may need to use an older compiler for it to look for the older library. If you're not developing on CentOS/RHEL, continue on.
My plan of attack today is to compile glibc from source. This means using a compiler that was released around the same time as the older version of glibc. You may run into some stumbling blocks (such as needing an older version of buildutils, etc.), but my hope is once the libc.so.5 is compiled and installed into /usr/local/lib my application will find that before it finds libc.so.6 in /lib.
So there it is. It's not for the faint of heart, and it's definitely not a quick solution. Today I plan on testing this out, so I can't really say it's the right solution. Please, hivemind.. if I'm flat-out wrong correct me and save this poor soul from this winding torturous road :-)
EDIT: link to glibc sources
Related
Dear expert community,
I so often face problems that software will not compile or work because libraries (specifically .so files) are too new.
If I try to install the old library (apt-get on Ubuntu) I can get errors that it is "not installable" because of conflicts...
So following problems arise in my mind:
1) how to install old libraries/packages together with newer ones for example on Arch Linux or Ubuntu Linux ?
2) how to avoid conflicts: the older library should be used (linked) only with the "problematic old" software and/or if I specify this explicitly ?
3) how can I check with cmake, make or the autotools if a specific (old) library version is installed and in case not automatically get it and install it and use it without conflict with a newer version ?
Thank to any expert for a help
Linux package managers normally don't allow installing multiple versions of the same package. You have to install older versions yourself, by hand, from source, preferably to some private place like /usr/old-versions.
You link problematic software like this:
<link command> -L /usr/old-versions/lib -Wl,-rpath=/usr/old-versions/lib
and it automatically uses the old version of the library.
There is no way to do that automatically.
Note that you may need to compile against older versions of library headers too, not just link against old versions of the libraries.
Very often we need to install software from its source code. Most of the time I just hit "make world" or "make all" then it will work like a charm. But some other time we see make errors, and we need to install other packages in order to let the make go through. This is particularly a problem for compiling low-level systems, such as a Linux kernel or Xen hypervisor.
I have one experience with Xen 3.4. Maybe it has been documented in some corner documents, but it depends on udev-125 to work properly. The weird thing is it functions well most of the time when udev version is 160+, it only breaks in certain cases! It took me a few MONTHS to find out it was because of the wrong udev version!
To make developers' life easier, when a source code is made successfully in one machine, is there some tools to record the list of packages and versions of that machine? Such a 'snapshot' should be shipped with the source code as well, so that when someone meets the make error they at least have a successful 'snapshot' for reference.
Is there such a tool already?
If your software depends on a specific version of a dependency, you should write a check for your configure script/cmakefile/etc. that tests the version of the dependency and bails out if the wrong version was found.
Comparing the output of config.log (a file created by a configure script) can also help diagnose problems like you encountered.
I already searched on the net a way to update the SQLITE3 version of Xcode, but I didn't found any working way. It is a way to do it?
If you want to use your own version of sqlite3, perhaps because you want to use newer features only provided by a later version, then probably the best thing to do would be to create an Xcode static library project to build sqlite3 and then include that library with your app (statically linked). This will avoid using the system version.
This should be fairly trivial, given the number of source files that make-up sqlite3.
You could probably make a dynamic library version, but that's slightly more complicated, though certainly possible.
I have a problem on my mac when trying in R to produce png images.
I am getting this warnings:
libpng warning: Application built with libpng-1.2.26 but running with 1.5.2
I am running the R 2.14 version using the R-studio GUI.
I am not excatly sure about the libpng problem. When I am doing locate libpng-config I'm getting several hits, some with libong-config12, some with libpng-config14, some without nay numbers:
ayeroslaviz:~ ayeroslaviz$ locate libpng-config
/Applications/XAMPP/xamppfiles/bin/libpng-config
/Library/Frameworks/GTK+.framework/Versions/2.18.X11/Resources/bin/libpng-config
/opt/local/bin/libpng-config
/usr/X11/bin/libpng-config
/usr/local/bin/libpng-config
When doing which libpng-config I'm getting: /usr/local/bin/libpng-config
Is there a way to uninstall older versions of libpng or update the paths to the right version. Unfortunately I am not even sure, what thesource of this warning, so I hope I gave here all the needed information.
I would be grateful for anyone who gives me a hint about how to solve this problem.
thanks
A.
Fortunately, you're using a Mac, so there's a simpler (but not documented) method.
quartz.save('my_filename.png', type='png')
Note that the image you want to save must be the currently active quartz window.
If your code still works, then don't worry about it. The fact this this is a warning rather than an error message means that there might be a problem, not that there definitely is a problem. IF you don't want to see the warning, wrap your R code in a call to suppressMessages.
suppressMessages(code_to_call_libpng)
This problem could occur because RStudio (or some other library you are using in your project) is using in-built libpng libraries (v1.2) and when the application run, the version installed in the system is v1.5: http://www.libpng.org/pub/png/pngfaq.html#mismatch. If this is the point, you could try to upgrade RStudio libpng libraries or downgrade system libpng ones.
I just installed homebrew and saw a message from the install script that said I should consider removing the following "evil" dylibs as they might break builds. Has anyone done this? And if so, did you later find out that you actually needed them?
Here's the dylib list:
/usr/local/lib/CHBrowserView.dylib
/usr/local/lib/libgnsdk_musicid_file.dylib
/usr/local/lib/libgnsdk_sdkmanager.dylib
/usr/local/lib/libjson.0.0.1.dylib
/usr/local/lib/libmusicid_osx.dylib
/usr/local/lib/libpcre.0.0.1.dylib
/usr/local/lib/libpcrecpp.0.0.0.dylib
/usr/local/lib/libpcreposix.0.0.0.dylib
NO. If you have something in /usr/local/lib, in all likelihood its because you built it and installed it.
It's an annoying and egotistical error message for Brew to assume that any libraries in /usr/local/lib are 'evil' simply because Brew doesn't know about them.
It is possible that you might have an 'older' version that conflicts with something Brew builds, but.. guh. It'll be painfully obvious when the program dies. And more likely than not if the application tries to dyload it, it also means that when Brew is building things it'll try to link against the old lib anyway. As long as it's arch / version compatible it's no biggie.
It'll also be painfully obvious when something you built pre-Brew can't find the shared library you removed. And given that you may not have the source laying around (or remember how you configured it in the first place..)
I strongly suggest keeping the old libraries around.