Linux no version information available required by

What does «psql: /usr/pgsql-11/lib/libpq.so.5: no version information available (required by psql)» actually mean?

UPDATE1: As requested by @LaurenzAlbe output for rpm -qa|grep postgres command is:

[nikola@192 ~] $ rpm -qa|grep postgres postgresql-11.7-2.fc30.x86_64 postgresql11-11.8-1PGDG.f30.x86_64 postgresql11-libs-11.8-1PGDG.f30.x86_64 postgresql11-server-11.8-1PGDG.f30.x86_64 postgresql-server-11.7-2.fc30.x86_64 

I’ve ran dnf remove postgresql postgresql-server command -> databases are still there and I can access them via pgAdmin4 and psql: /usr/pgsql-11/lib/libpq.so.5: no version information available (required by psql message is no longer showing up. But, there is now new issue -> when I access postgres shell in terminal using sudo su — postgres command and then perform psql some-database-name postgres I get message

bash: psql: command not found.
Install package ‘postgresql’ to provide command ‘psql’? [N/y]

I presume this is asking me to install AGAIN Fedora package which in 1st place I am trying to get rid off (to not show psql: /usr/pgsql-11/lib/libpq.so.5: no version information available (required by psql) message).

Any suggestion how to solve this without installing Fedora package but from PostgreSQL Global Development group?

P.S. BTW, I’ve installed Postgres server by following this link which uses PGDG packages (but something didn’t work right on my machine and I guess I’ve been offered by Fedora30 OS to install Fedora packages which is obviously what I did 🙂 ).

Источник

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

Hm. Unfortunately I don’t know much about Linux. Libs on /usr/local have a specific meaning? It’s always an «relic» if it’s sitting there?

Well /usr/local means it was compiled locally, not supplied by the OS distribution. Sometimes people do that because they need a newer version than what came with the distribution, then the distribution updates to something newer and the one in /usr/local gets forgotten. That was just a guess though. If you didn’t compile zlib yourself, someone else with root access to the machine did. Ask them why. and maybe try LD_LIBRARY_PATH=/usr/lib git —version to override it until you get an answer.

That’s not a git configuration, it’s a dynamic linker configuration. You could replace /usr/bin/git with a wrapper script, but that’s more like postponing the problem than fixing it. You need to sort out what’s been done in /usr/local and whether the local zlib is still needed by any other applications.

6 Answers 6

/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.

ldd /usr/local/bin/* /usr/local/sbin/* | less +/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)

mkdir /root/local-libz-backup mv /usr/local/lib/libz* /root/local-libz-backup ldconfig 

Источник

no version information available (required by /usr/bin/ssh)

How to fix this error? Note: I compiled and installed the openssl . After that, I installed ssh through apt-get .

4 Answers 4

I compiled and installed the openssl. After that, I installed ssh through apt-get.

These are probably two different versions of OpenSSL. You will probably be OK since 1.0.0 is binary compatible with 1.0.1, 1.0.2, etc (it won’t be binary compatible with 1.1.0, however).

Your ssh is probably using the version of OpenSSL in /usr/lib/x86_64-linux-gnu/ . You should use LD_PRELOAD to ensure your version of OpenSSL is being used (assuming binary compatibility, of course).

If you don’t want to use LD_PRELOAD and friends, then build ssh from sources. Be sure to specify an rpath to ensure the link editor uses your version of OpenSSL, not he system’s version. That is, your LDFLAGS should include something like -Wl,-rpath, . That’s in addition to the customary -lcrypto , -lssl and -L .

If you are on Mac OS X, then be advised that linker options like -Bstatic and -rpath are silently ignored. You will encounter mysterious crashes due to incompatible binaries because OS X provide 0.9.8.

no version information available

As for no version information, I have no idea. ssh can use either OPENSSL_VERSION_NUMBER at compile time or SSLeay / SSLeay_version at runtime. See OPENSSL_VERSION_NUMBER(3) for details.

Perhaps I’m misreading things, but I don’t see an error anywhere in the post.

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

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

(Just to be sure we are starting fresh.)

Now for the really mind boggling part.

./config --prefix=/usr/local --openssldir=/usr/local/openssl shared -Wl,--version-script=openssl.ld -Wl,-Bsymbolic-functions 

make make test make install ldconfig 

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.

Thanks for the tip! Here is an updated openssl.ld which handles 1.0.2 gist.github.com/Scottmitch/71a89d98b3af272aab6ae6bfed122c5a

I have just discovered that my above solution breaks certain binaries that require an OPENSSL_1.0.1 version. Like curl for example. apt-file search will no longer work with my solution as that uses curl. So some binaries want a 1.0.0 version and others want a 1.0.1 version.

I believe the solution lies in a editing of the openssl.ld file. So that some binaries will get the 1.0.0 version and other will get a 1.0.1 version. At the moment this is beyond me. Maybe somebody else can solve this.

If you want to install custom-compiled libraries, don’t break your system by installing to prefixes /usr/local , /usr or / . Debian/Ubuntu, for example, will pick up custom libraries in /usr/local/lib the next time ldconfig is invoked because it’s usually listed in /etc/ld.so.conf.d/libc.conf .

Here’s a throw-away box with openssl 1.0.2e make install ‘ed to —prefix=/usr/local and then run ldconfig (with no arguments, which updates /etc/ld.so.cache ):

# ldconfig -p | egrep 'lib(crypt|ssl)' libssl.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libssl.so.1.0.0 libssl.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.1.0.0 libssl.so (libc6,x86-64) => /usr/local/lib/libssl.so libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so libcrypto.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libcrypto.so.1.0.0 libcrypto.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 libcrypto.so (libc6,x86-64) => /usr/local/lib/libcrypto.so libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so libcrypt.so.1 (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/libcrypt.so.1 libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.24) => /lib/x86_64-linux-gnu/libcrypt.so.1 libcrypt.so.1 (libc6, OS ABI: Linux 2.6.24) => /lib32/libcrypt.so.1 libcrypt.so (libc6,x32, OS ABI: Linux 3.4.0) => /usr/libx32/libcrypt.so libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.24) => /usr/lib/x86_64-linux-gnu/libcrypt.so libcrypt.so (libc6, OS ABI: Linux 2.6.24) => /usr/lib32/libcrypt.so 

Notice how the custom-compiled ones override libs from the openssl package.

Instead, the solution is to vendor custom libraries and binaries into isolated directories that are independent from the default ld.conf and PATH.

Install software to /opt/$WHATEVER-$VERSION/

Then, if you want to use custom-compiled binaries in /opt/$WHATEVER-$VERSION/bin , append that to the PATH (DO NOT PREPEND, because of the risk of breaking the system).

For static linking $WHATEVER to something else

export CFLAGS="$CFLAGS -I/opt/$WHATEVER-$VERSION/include" \ CXXFLAGS="$CXXFLAGS -I/opt/$WHATEVER-$VERSION/include" \ LDFLAGS="-lwhatever -L/opt/$WHATEVER-$VERSION/lib" 

For shared linking $WHATEVER to something else

Same as above but add -Wl,-rpath,/opt/$WHATEVER-$VERSION/lib to LDFLAGS

Another thing to do is instead of make install use checkinstall to build a removable package where the full package name includes custom-$WHATEVER-$VERSION to allow easier version management to avoid breaking custom packages through incompatible upgrades.

Источник