Linux lib no version information available

What does the «no version information available» error from linux dynamic linker mean?

In our product we ship some linux binaries that dynamically link to system libraries like «libpam». On some customer systems we get the following error on stderr when the program runs:

The application runs fine and executes code from the dynamic library. So this is not a fatal error, it’s really just a warning.

I figure that this is error comes from the dynamic linker when the system installed library is missing something our executable expects. I don’t know much about the internals of the dynamic linking process . and googling the topic doesn’t help much. 🙁

Anyone know what causes this error? . how I can diagnose the cause? . and how we could change our executables to avoid this problem?

Update: The customer upgraded to the latest version of debian «testing» and the same error occurred. So it’s not an out of date libpam library. I guess I’d like to understand what the linker is complaining about? How can I investigate the underlying cause, etc?

5 Answers 5

The «no version information available» means that the library version number is lower on the shared object. For example, if your major.minor.patch number is 7.15.5 on the machine where you build the binary, and the major.minor.patch number is 7.12.1 on the installation machine, ld will print the warning.

You can fix this by compiling with a library (headers and shared objects) that matches the shared object version shipped with your target OS. E.g., if you are going to install to RedHat 3.4.6-9 you don’t want to compile on Debian 4.1.1-21. This is one of the reasons that most distributions ship for specific linux distro numbers.

Otherwise, you can statically link. However, you don’t want to do this with something like PAM, so you want to actually install a development environment that matches your client’s production environment (or at least install and link against the correct library versions.)

Advice you get to rename the .so files (padding them with version numbers,) stems from a time when shared object libraries did not use versioned symbols. So don’t expect that playing with the .so.n.n.n naming scheme is going to help (much — it might help if you system has been trashed.)

You last option will be compiling with a library with a different minor version number, using a custom linking script: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html

To do this, you’ll need to write a custom script, and you’ll need a custom installer that runs ld against your client’s shared objects, using the custom script. This requires that your client have gcc or ld on their production system.

Источник

no version information available

I’m using Ubuntu 12.04 — server and consistently getting:

/usr/lib/libcrypto.so.1.0.0: no version information available (required by /usr/lib/libpython2.7.so.1.0)

/usr/lib/libssl.so.1.0.0: no version information available (required by /usr/lib/libpython2.7.so.1.0)

error messages without any pattern for why. It can be something as simple as running vi.The files are there and they are not links.

This started happening a little after compiling and installing OpenLDAP, using the instructions from their site while learning the basics of the ldap server. I have removed openLDAP of course to try and remove the problem. I have also reinstalled OpenSSL and libssl1.0.0 to try and test that solution.

Any help will be greatly appreciated, google hasn’t been useful unfortunately.

3 Answers 3

I suppose I should get right to the point.

Problem: libssl.so.1.0.0 and libcrypto.so.1.0.0 no version information available warning/error.

I SOLVED IT. YAY. (Fireworks should be going off and stuff.)

After much research, time and effort, (took weeks), here’s what I finally ended up doing.

In the directory where you ended up extracting the source code for your version of openssl 1.0.1h (Should work for other versions too.) I create a file called openssl.ld

In this file put this.

Answer

save it. Now type in.

make clean (Just to be sure we are starting fresh.)

Now for the really mind boggling part.

And that should do it. (It’s so simple. No patching required.)

I have applied this solution to Debian Wheezy both 32 and 64 bit versions. And have made an observation. The 64 bit version automatically defaults to the new libssl.so.1.0.0 and libcrypto.so.1.0.0 files that are created in the /usr/local/lib directory. The 32 bit version does not. Which is why I had thought at first that the 32 bit version of Debian Wheezy didn’t suffer from this problem, but it does once you get the 32 bit version to use the new openssl libraries in the /usr/local/lib dir.

Using the ldd command to test what libraries the binaries are using was invaluable in figuring this out too.

Have a nice day.

I was also getting that annoying warning message after compiling and installing the latest version of openssl from source (openssl-1.0.1f). After some research along with some trial and error, I was able to fix the issue for my particular scenario. It basically came down to exactly what the warning message says. There is no version information available in the libraries that were built from source. That is something that the Ubuntu team has added in their distribution. So, the solution is to recompile your openssl source after patching it with the version script that is included in the Ubuntu package distribution for openssl.

Источник

Getting rid of «git: /usr/local/lib/libz.so.1: no version information available (required by git)»

For every git command I try to run, I get this message. Example:

How can I get rid of this?

Edit 1:

Trying to update zlib1g :

Edit 2:

I’m on Debian Lenny (5), so, unfortunately, using apt-get isn’t that easy.

5 Answers 5

/usr/local is meant to be used for installation of programs compiled locally, by the machine’s administrator. Simple programs just go into /usr/local/bin and are run from there by putting /usr/local/bin into the PATH environment variable. This allows the administrator to provide the users access to additional commands, which aren’t included in the OS. There’s nothing stopping root from installing new things into /usr/bin but the convention is that /usr/bin is managed by the OS distributor’s packaging tools, and keeping local stuff separate makes things a little less confusing.

Sometimes a local program needs a library that isn’t provided by the OS distributor, and the library goes into /usr/local/lib and everything works.

When there’s a version conflict — the OS supplied libz.so of version X but a local program needs libz.so version X+1 or needs libz.so to be compiled with a special option — things start to get complicated. Installing the newer library in /usr/local/lib is probably OK at first.

Every program looks for libraries based on /etc/ld.so.conf and if /usr/lib is given priority there, the /usr/local programs won’t find the newer library that they need. So /usr/local/lib is usually given priority. Older programs finding a newer library is usually not a problem because the libraries are backward-compatible.

Years later, after a few OS upgrades, the library in /usr/lib is now version X+2 and the one in /usr/local/lib is still version X+1, and now programs from /usr/bin are loading the old /usr/local/lib version, and misbehaving. This can probably be fixed by removing the old library. The /usr/local/bin program that needed version X+1 will find version X+2 in /usr/lib and work fine. But only if the need for a newer version was the reason for installing version X+1 locally in the first place.

To probe for potential problems before doing the removal, look for anything under /usr/local that uses libz.

If you find anything that references libz, try running it with LD_LIBRARY_PATH=/usr/lib to make sure it still works. Assuming nothing breaks, remove the local libz files (by moving them to a backup location so you can undo this if you have to)

Источник

How to diagnosis and resolve: /usr/lib64/libz.so.1: no version information available

I had a hell of a time installing lxml for Python 2.7 on CentOS 5.6. For some background, Python 2.7 is an alternative installation of Python on CentOS 5.6 which comes with Python 2.4 installed.

it was bulit from source per its instrucitons

However, after about 20 hours of trying I managed to find a workable solution and was able to install lxml .

Until, I notice the following error at the top of the interpreter:

This error is printed out everytime I run a script.

The script runs flawlessly, but this error is bothersome. After some digging I have seem to believe I have a wrong version of libz installed, that it is either an older version or built for a different platform.

I’m not quite sure how, I’ve only installed libz through yum , as far as I know. Although, I can’t quite remember every little thing I tried in my twenty hours of trying.

You may also be intereted in what my lib64 folder looks like, here is some information

Notice: the items that Say Jul 1st or Jun 30th are from me. I had initially moved these files into a backup folder as they seeemed to be duplicates and had a date after/during my problems I alluded to earlier that I had with lxml

One inclination is to completely remove Python 2.7 and re-install. I think having it install to /usr/local/ was a poor default choice. However, without the make uninstall option being present it seems to be a time consuming task for a solution I am not quite sure would solve my problem.

Источник

/lib/libstdc++.so.6: no version information available on Synology DSM Linux #33384

Comments

abock commented Mar 9, 2020

When running .NET Core apps ( netcoreapp3.1 ) using the latest generic linux-x64 .NET Core SDK on Synology’s DSM Linux distribution, the following is dumped to the console on app start:

It’d be lovely if this could be avoided. It’s rather noisy, but so far seems to be just that — everything seems functional otherwise.

Hardware	OS	Target Framework	.NET Core SDK
Synology RS-815+	DSM 6.2.2-24922 Update 4	netcoreapp3.1	3.1.102

The text was updated successfully, but these errors were encountered:

Dotnet-GitSync-Bot commented Mar 9, 2020

I couldn’t add an area label to this Issue.

Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.

janvorli commented Mar 9, 2020

abock commented Mar 9, 2020

It’s a toolchain issue that produces the generic linux-x64 binaries of .NET Core.

szyb commented May 12, 2020

@abock Did you deal with this error in DSM?

szyb commented May 14, 2020

I workaround this problem with following steps (all as root):

1. copy libstdc++.so.6.0.22 from my debian distro, and put it to /lib folder in DSM
2. chmod 555 libstdc++.so.6.0.22
3. change symbolic link libstdc++.so.6 to this file ( ln -f -s libstdc++.so.6.0.22 libstdc++.so.6 )
4. run dotnet —info
   It run without the error.

But isn’t the real issue here is not to lack of the file libstdc++.so.6.0.22 in dotnet runtime binaries?

janvorli commented May 14, 2020

But isn’t the real issue here is not to lack of the file libstdc++.so.6.0.22 in dotnet runtime binaries?

There is a set of 3rd party prerequisite libraries that dotnet depends on and that need to be installed on the target system. The distro maintainers are much better positioned to ensure that the libraries are up to date with possible security fixes. And some of them we would not be able to carry in our packages anyways due to their licenses.

szyb commented May 14, 2020

@janvorli Ok. It sounds reasonable.
I only think that requirements page (https://docs.microsoft.com/en-us/dotnet/core/install/dependencies?pivots=os-linux&tabs=netcore31#install-net-core-for-supported-alpine-linux-versions-64-bit) should have minimum version number included besides on the name of the package as it does matter.

janvorli commented May 14, 2020

@szyb you are right, we should list the minimal required versions there.

Источник