I want to install psycopg2 on Windows 8.1 x64 computer and I'm using python 2.7.6 from python.org. As I launch the installer as administrator, I got this error,
I press confirm and next button, but I can't choose or type my python directory.
I have seen this post after I got those problem, Psycopg installation on windows, but it seems that that is a different case as mine.
How to successfully install psycopg2 on Windows 8.1 x64 computer？
Install the binary distribution of psycopg2 for the same architecture as your Python version.
Your Psycopg2 architecture must match the architecture of the Python binary you installed. So if you have a 32-bit Python 2.7 you must get the 32-bit psycopg2; if you have the 64-bit Python 2.7, you must get the 64-bit pycopg2.
This applies to any Python module that contains binary modules, not just psycopg2.
Related
I had Python 3.5 on Ubuntu 16.04 and then I installed Python 3.7 and made it the default Python.
Now most of the programs I run go Python 3.7 but some run on 3.5 (I don't know why).
Also, the system says that there is a problem with python 3.5 but I can't figure what it is.
Can anyone help?
Thank You
Configure PYTHON_PATH pointing proper library path or set path environment variable pointing to correct Python version.
Running a Laravel installation on a RedHat Enterprise Linux 7 server using PHP 7.1. I can see php-pgsql.x86_64 listed in the available yum packages, but it doesn't appear to be compatible with PHP 7.1 (and indeed is listed as version 5.4.16-43.el7_4.1).
On a lark, I tried installing it anyway and physically moved the pgsql.ini and pdo_pgsql.ini files from /etc/php.d into the relevant PHP 7.1 folder /etc/opt/rh/rh-php71/php.d/ (and did the same with the .so files they reference), but that returns an error indicating that the package couldn't be read (undefined symbol: file_globals_id in Unknown on line 0).
Has anyone managed to get PHP 7.1 talking to PostgreSQL on RHEL 7?
The sysadmin who originally created the server for me set me straight. The problem was I was looking in the wrong repository for the packages I needed for my particular PHP installation. Running the following two commands did the trick:
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-odbc
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-pgsql
We then added those two packages to the Ansible playbook so future generations would not suffer needlessly.
Are there any issues with installing Python 3.3 after installing Canopy Express (which has Python 2.7)? I recently installed Canopy to take advantage of the packages it bundles. I see that it has uses version 2.7 of python, but I would very much like to use the latest and greatest version of Python as I am new to python and just learning it. However I would like to make sure that installing Python 3.3 doesn't break any of the features of Canopy.
You can install Python 3 in parallel to Canopy, but you will not be able to run Canopy on Python 3.
I have created an executable (.exe) of a perl script on a 64-bit linux kernel. It executes correctly in this environment.
When the executable is run in 64-bit Windows 7, the following error message is displayed:
The version of this file is not compatible with the version of Windows
you're running. Check your computer's system information to see
whether you need x86 (32-bit) or x64 (64-bit) version of the program,
and then contact the software publisher.
Given that the source and destination OS's were both 64-bit, I'm not sure that the architecture of the build is the issue. Are there any special considerations to make a compiled perl program execute properly in Windows? Thank you.
Executable files are not compatible across platforms. They will run on the original platform only unless they are explicitly cross-compiled to a different target. That's actually the reason we use interpreted languages. What you want to do is not possible because the Windows and Linux APIs, libraries, and well just about everything are completely different.
This is why you need to download a different version of a program for linux/windows/mac.
I've got 64-bit Vista with ActiveState Perl "v5.10.0 built for MSWin32-x64-multi-thread" and I'm trying to get the Crypt::SSLeay package installed along with versions of libeay32.dll and ssleay32.dll.
I've done this before on a Win32 machine using the 'uwinnipeg' server, but I'm running into issues with my 64-bit system.
ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd
ppm install failed: The PPD does not provide code to install for this platform
I've tried a straight ppm install which seemed to work, but verification fails and I don't see any sign of the dll files?
C:\Perl64\bin>ppm install Crypt::SSLeay
Downloading ActiveState Package Repository packlist...done
Updating ActiveState Package Repository database...done
Syncing site PPM database with .packlists...done
No missing packages to install
C:\Perl64\bin>ppm verify Crypt::SSLeay
ppm verify failed: Package 'Crypt::SSLeay' is not installed
Does anyone know where/how I could get versions that are compatible with my PC?
There are a few issues here: First, AFAIK, you need OpenSSL v1.0.0 or greater for Windows 64. Second, until recently, Makefile.PL in Crypt-SSLeay did not detect correctly OpenSSL versions greater than 0.9.x.
I think you want to upgrade at the very least to Perl 5.10.1 as it fixed a number of crucial performance related bugs.
If you install mingw via ActiveState's ppm (I am assuming ppm install mingw would work even though I haven't tried it on a 64-bit system), you can use it to build OpenSSL 1.0.0a and Crypt-SSLeay.
Update: You probably don't need Crypt::SSLeay. See:
DO YOU NEED Crypt::SSLeay?
Does your code really depend on Crypt::SSLeay?
Don't declare a dependency on Crypt::SSLeay (or IO::Socket::SSL either).
Also useful:
Building OpenSSL 1.0.1g on 64-bit Windows Pro 8.1 with Windows SDK 7.1
Compile Vim and OpenSSL with Visual Studio 2013 Community Edition.
Sinan has very recently released a new version of Crypt::SSLeay which might clear up some Windows installation issues. I doubt it's made its way into a PPM yet.