Skip to content
This repository has been archived by the owner on May 29, 2020. It is now read-only.

Can't install without Visual Studio 2003 #1

Open
GadgetSteve opened this issue Oct 2, 2013 · 4 comments
Open

Can't install without Visual Studio 2003 #1

GadgetSteve opened this issue Oct 2, 2013 · 4 comments

Comments

@GadgetSteve
Copy link

I need to carry on supporting tools developed with python 2.5 but have problems using pip due to the lack of SSL - this package is the recommended fix for the problem but the recommended install method is pip - which is what I am trying to fix or setup.py install - trying the latter I get: error: Python was built with Visual Studio 2003 which I do not have.

@nlsp
Copy link

nlsp commented Oct 24, 2014

@GadgetSteve : Did you ever succeed in building it? I do have a VC .NET 2003 compiler but the package does not compile… Anyone care to look into ancient win32 compatibility bugs?

Will share transcripts and hacks in case i’m not alone ;-)

@GadgetSteve
Copy link
Author

Not so far - I have been concentrating on updating the tools + deployment package to python 2.7.X - the main thing is that I need to provide them in .exe format and the visual studio deployment model means that I need to bundle the exes into an installer with InnoSetup.

@nlsp
Copy link

nlsp commented Oct 25, 2014

Well okay, I could try help out building an ssl installer by doing just python setup.py bdist_wininst but there are a few things in the way that one should be aware of:

  1. ssl/_ssl2.c does not compile with VC7
ssl\_ssl2.c(933) : error C2275: 'EVP_PKEY' : illegal use of this type as an expression
        C:\Tools\OpenSSL\include\openssl\ossl_typ.h(131) : see declaration of 'EVP_PKEY'
ssl\_ssl2.c(933) : error C2065: 'key' : undeclared identifier
ssl\_ssl2.c(934) : warning C4047: ‘function' : 'EVP_PKEY *' differs in levels of indirection from 'int'

It turns out the definition of EVP_PKEY *key = X509_get_pubkey(certificate); in the middle of a code block is unsupported. That’s easily fixed by moving the variable declaration to the top of the function.

  1. the linker does not understand the -static switch which setup.py assumes would work.

By defining SSL_DYNAMIC=1 in the environment we can link dynamically.

  1. setup.py hard-codes libs = [‘ssl’, ‘crypto’, ‘wsock32’] which OpenSSL did not install in my case.

Changing to ssleay32 and libeay32 fixes that. But since we are now linking dynamically the actual DLLs are still required at runtime and they will not be installed by the python distutils installer.

So, to wrap this all up, this is what i’ve done to get to a working extension:

  • downloaded openssl-1.0.1j.tar.gz
  • configured, built and installed as per INSTALL.W32 (using no-asm and installed to C:\Tools\OpenSSL)
  • modified ssl\_ssl2.c to compile under VC7 as per above
  • set the following environment variables in a V.S. .NET 2003 command prompt window:
    • set C_INCLUDE_DIR=C:\Tools\OpenSSL\include
    • set C_LIB_DIR=C:\Tools\OpenSSL\lib
    • set SSL_DYNAMIC=1
  • modified setup.py to look for the actual installed openssl libraries
  • built with python2.4 (in my case) using python setup.py bdist_wininst

If that would save you headaches I can repeat the whole process once more using Python 2.5.x and attach (if allowed here) or send the .exe. Oh, and it is all 32-bit only ;-)

@GadgetSteve
Copy link
Author

@nlsp Thanks for the information it will come in very useful if I have to stick with 2.5.4 much longer - hopefully we are going to push ahead with the move up to Python 2.7 - then of course I need to start making the codebase Python 3.3+ compatible...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants