I'm getting the following exception when I use python binding. I thought client binding apis are backward compatible. If not how/where can I get the python library corresponding to the version 610
fdb.api_version(610)
File "/usr/local/lib/python2.7/dist-packages/fdb/__init__.py", line 76, in api_version
"%d, but the installed library supports a maximum version of %d." % (header_version, max_supported_ver))
RuntimeError: This version of the FoundationDB Python binding is not supported by the installed FoundationDB C library. The binding requires a library that supports API version 620, but the installed library supports a maximum version of 610.
The host from where you are running the python client also needs to have the foundation db client installed.
For example for 6.2.20 on Ubuntu the download link for client is here.
For version 610 you need to install foundationdb version 6.1.XX (I used 6.1.11). You can update the foundationdb package you already installed with
pip install -I foundationdb==6.1.11
The -I will replace whatever installed version you have with the one you are about to install.
Related
I'm trying to develop .NET Core in openSuse. I did install the SDK and everything in tutorials. Now, when I try to run dotnet new console command, I get this error:
No usable version of the libssl was found
Aborted (core dumped)
I found this answer: (.NET Core 2.1 SDK Linux x64 No usable version of the libssl was found), but didn't get what should I do to solve problem. They seems are deep-linuxer (which I'm not, I'm just trying to learn linux). Have any idea how to run the command?
UPDATE: System info:
openSUSE Leap 15.0
Kernel Version 4.12.14-lp150.12.22-default
OS Type:64-bit
I was having the same problem running sqlpackage on Ubuntu 20.04 while dotnet was working regularly.
dotnet is distributed through apt as well as sqlserver, but for some reasons sqlpackage is instead distributed via zip here (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-ver15) and is still affected by missing libssl1.0.
Solved with
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
Can you install the libopenssl1_0_0 packages? .NET Core should pick it up and use it.
A slightly longer explanation for anyone who is curious:
OpenSSL is one of the most common cryptographic libraries used on Linux. It has multiple versions. Version 1.0 is kind of old, but heavily used. 1.1 is the newer version that was (relatively) recently released. 1.0 and 1.1 are not compatible. An application that expects 1.0 can not build against 1.1, nor run against it.
.NET Core 2.1, and all earlier versions only support OpenSSL 1.0.
Many Linux distributions are starting to make OpenSSL 1.1 the new default. But most of them still have a package for 1.0. So you just need to find and install that. On Fedora it's compat-openssl10. For openSuSE, it's libopenssl1_0_0. Then .NET Core will find it, pick it up and use it automatically.
Edit: As of March 2019, this shouldn't be required. We have updated .NET Core 2.1 and later to pick up and work with either OpenSSL 1.1 or 1.0 (whatever is available). So this problem should no longer happen with recent releases of .NET Core.
Ubuntu 22.04
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
Still get this on Fedora 30 (with compat-openssl10 installed) when using the sqlpackage tool (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017).
$ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca
Runtime Environment:
OS Name: fedora
OS Version: 30
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.2.203/
Host (useful for support):
Version: 2.2.4
Commit: f95848e524
.NET Core SDKs installed:
2.2.203 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Dotnet works fine on it's own. But running sqlpackage does not work:
$ sqlpackage /tsn:localhost /tu:xx /tp:yyy /A:Import /tdn:mydb /sf:mydb.bacpac
Importing to database 'mydb' on server 'localhost'.
No usable version of the libssl was found
Aborted (core dumped)
I looking up "No usable version of the libssl was found" in github. You'll find many variants of the .Net core security library in C, each varient has very specific dll loads for exact libssl libraries and everything has to match perfect despite it being named differently in many.
For raspberry pi / debian it wants libssl 1.0.2 exactly, nothing else.
sudo apt-get install libssl1.0.2
should do the trick for the pi! I can't speak to other variants.
i have 2 oracle client installed in linux machine. 10.2 and 12.2.
Second one i have to use for cx_oracle and older one is needed for other older implementation which i cant touch.
when i add second 12.2 oracle client library in LD_LIBRARY_PATH path and running simple oracle connection python program, it is giving me below error
cx_Oracle.DatabaseError: DPI-1050: Oracle Client library is at version 10.2 but must be at version 11.2 or higher
How can i use the newer version of client library without touching the old config?
Write a shell script that lists the 12.2 Oracle Client library in LD_LIBRARY_PATH before other Oracle libraries, and then invokes Python.
#!/bin/sh
export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
python "$#"
I install the latest qt version from the official website http://www.qt.io/qt5-4/ successfully. I follow this tutorial http://sysads.co.uk/2014/05/install-qt-5-3-ubuntu-14-04 and install the qt 5.4 version. Besides, I have the Ubuntu repository version of qt 5.2.1 installed.
Now I want to make the default version of 5.4 due to a program can't work well in the old qt5 version. That is to say, when I start a program which need to use qt5 library the program will use the version 5.4 rather than the version qt 5.2. Though I have installed the version 5.4 and 5.2, the program still use qt 5.2 version.
I try to use qtchooser to choose the 5.4 version as the default option, however, the program installed in the system still use the qt 5.2 library.
I endeavor to modify the related files regarding qtchooser, nothing changes.
If the library version is not in some regular repository, I would strongly suggest not relying on the user to install it somehow from an "unofficial" install location. Or provide a package for the library version yourself to install alongside your application. But don't replace the system Qt version. That would be Bad®.
Instead, either compile your program with a specific rpath, or wrap your program in scripts that use something like LD_PRELOAD and/or LD_LIBRARY_PATH to load the library version you're shipping in your application package.
Both ways are clunky, and I would try to at least work around the Qt version bug if at all possible.
The latest Qt version (non-alpha) actually is Qt 5.5.
If you install it through the installer provided by Qt, you should change the default Qt version by editing/creating:
/etc/xdg/qtchooser/default.conf
which should contain first the bin directory, then the lib directory, for example:
/opt/Qt/5.5/gcc_64/bin
/opt/Qt/5.5/gcc_64/lib
At least this works for the qmake version. Otherwise you might need to change LD_LIBRARY_PATH as commented by rubenvb.
I'm getting this error when i try to run apache:
./httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
when i do a search for the lib i receive this:
/usr/lib/libpcre.so.1
/usr/lib/libpcre.so.1.2.1
/usr/lib/libpcre16.so.0
/usr/lib/libpcre16.so.0.2.1
/usr/lib/libpcre32.so.0
/usr/lib/libpcre32.so.0.0.1
/usr/lib/libpcrecpp.so.0
/usr/lib/libpcrecpp.so.0.0.0
/usr/lib/libpcreposix.so.0
/usr/lib/libpcreposix.so.0.0.2
/usr/lib64/libpcre.so.1
/usr/lib64/libpcre.so.1.2.1
/usr/lib64/libpcre16.so.0
/usr/lib64/libpcre16.so.0.2.1
/usr/lib64/libpcre32.so.0
/usr/lib64/libpcre32.so.0.0.1
/usr/lib64/libpcrecpp.so.0
/usr/lib64/libpcrecpp.so.0.0.0
/usr/lib64/libpcreposix.so.0
/usr/lib64/libpcreposix.so.0.0.2
I tried to upgrade my pcre, to get the so.0 :
Package pcre-8.33-11.fc20.x86_64 already installed and latest version
Nothing to do
I'm out of ideas, hope someone can help.
This error is occurring because the version of Apache that is currently installed was built against an older version of pcre.
First upgrade Apache to the latest version in the Fedora repositories. The latest version should have been built against the newer pcre shared object.
If you can't, or won't upgrade Apache, you can downgrade the pcre package to the first version that contains libpcre.so.0, which is 7.8 I think.
If you need a quick fix and aren't using this web server for anything too serious you may be able to make it work by sym-linking libpcre.so.0 to libpcre.so.1.
lastly, you could rebuild Apache manually, which should use the pcre that is currently installed.
I'm running the latest Ubuntu (14.04) and have just downloaded the Node.js tarball. I'm not very familiar with Python though, and although I love Ubuntu, I'm also not familiar with the process of downloading and installing stuff on Linux as well :/
It says on the Node.js download page that Python 2.6 or 2.7 is required, but I have found that newer versions of Python are available. Will a newer version of Python build it correctly?
If you're not familiar with Linux then I don't think you want to compile node.js yourself from source. You can still use the binaries.tar.gz
There are Ubuntu packages that will install node.js for you! Installing from a package manager is easier, try https://github.com/joyent/node/wiki/installing-node.js-via-package-manager#debian-and-ubuntu-based-linux-distributions
As for building from source, there are known issues with Python 3, ref https://github.com/joyent/node/wiki/installation#known-issues, so maybe stick with 2.6 or 2.7
Python versions starting with and including 2.6 up through before 3.0 should work fine. Python 3 brought some backwards incompatible changes with Python 2.x and AFAIK gyp has not been updated to support Python 3 yet.