Thanks Graham for the hint. I found a pycrypto compiled with MinGW and
it worked. But I have similar issues with other modules so the problem
was still there.

Googling i found this post 
http://psycopg.lighthouseapp.com/projects/62710/tickets/20#ticket-20-6
which explains quite clearly and deeply the issue and suggests that
"The ways to resolve the situation is to embed a manifest into apache
or embed it into psycopg" and the author then gets for the second. I
have tried the first in order to solve the issue for all potential
cases.

I downloaded Microsoft Windows SDK, which includes "mt.exe", Microsoft
(R) Manifest Tool. With this i did a:

mt.exe -inputresource:"C:\Python26\python.exe";#1 -out:"C:
\Python26\extracted.python.exe.manifest"

Which exports the embedded manifest used in my current python.exe
(which works ok with all modules).

It looks like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></
requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
version="9.0.21022.8" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

>From here i stripped the trustInfo part and left just the dependency
one:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
version="9.0.21022.8" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Now i copied and renamed the result into httpd.exe.manifest and
executed a:

mt.exe -manifest:"C:\Program Files\Apache Software Foundation
\Apache2.2\bin\httpd.exe.manifest" -outputresource:"C:\Program Files
\Apache Software Foundation\Apache2.2\bin\httpd.exe";1

This command embeds a manifest file (the one extracted from
python.exe) into httpd.exe (which has no, otherwise i would have
needed to merge).

After this the problem was resolved!

I will see over next days if this has some noticeable drawback,
otherwise it would be an acceptable solution (at least in my case).

regards and thanks for help, af


On Apr 30, 9:32 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> On 1 May 2011 03:38, Alejandro <afrit...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
> > I have the following in httpd.conf:
>
> > LoadModule wsgi_module modules/mod_wsgi.so
>
> > WSGIScriptAlias /wsgi "C:/temp/wsgi_test.py"
>
> > <Directory "C:/temp">
> > AllowOverride None
> > Options None
> > Order deny,allow
> > Allow from all
> > </Directory>
>
> > Which with a wsgi_test.py like:
>
> > def application(environ, start_response):
>
> >    status = '200 OK'
> >    output = 'Hello World!'
>
> >    response_headers = [('Content-type', 'text/plain'), ('Content-
> > Length', str(len(output)))]
> >    start_response(status, response_headers)
>
> >    return [output]
>
> > works fine and returns Hello World, so i suppose that the basic things
> > work ok.
>
> > Now, if i add to the wsgi_test.py, a:
>
> > from Crypto.Cipher import AES
>
> > or
>
> > import pywintypes
>
> > i get loading errors, with Crypto for example:
>
> > [Sat Apr 30 14:32:27 2011] [info] mod_wsgi (pid=3756): Create
> > interpreter 'nb-alejandro.quipugmbh.com|/wsgi'.
> > [Sat Apr 30 14:32:27 2011] [info] [client 127.0.0.1] mod_wsgi
> > (pid=3756, process='', application='nb-alejandro.quipugmbh.com|/
> > wsgi'): Loading WSGI script 'C:/temp/wsgi_test.py'.
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1] mod_wsgi
> > (pid=3756): Target WSGI script 'C:/temp/wsgi_test.py' cannot be loaded
> > as Python module.
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1] mod_wsgi
> > (pid=3756): Exception occurred processing WSGI script 'C:/temp/
> > wsgi_test.py'.
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1] Traceback (most
> > recent call last):
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1]   File "C:/temp/
> > wsgi_test.py", line 3, in <module>
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1]     from
> > Crypto.Cipher import AES
> > [Sat Apr 30 14:32:27 2011] [error] [client 127.0.0.1] ImportError: DLL
> > load failed: The specified module could not be found.
>
> > if i run running wsgi_test.py from command line it works fine, no
> > complaints.
>
> > I have googled quite a lot and there seem to be different
> > explanations, the closest one to my problem apparently related to
> > manifests and being stripped in latest python versions (http://
> > bugs.python.org/issue4120) and apache not having any, but i am really
> > confused if i am looking in the right direction.
>
> > Any idea how to advance with this?
>
> The only solution is for the third party C extension (Crypto) to be
> built with a dependency on the required DLL. I am not a Windows person
> so don't know how that is done. It seems though some people have found
> that using mingw compiler instead of Microsoft compiler will
> automatically add the dependency without needing to modify the build
> files for the package having the issue.
>
> Another package from memory that has been affected by this has been
> SQLAlchemy. In later versions of that they are adding the dependencies
> themselves so will work under embedded systems that themselves don't
> link the required DLL.
>
> That the original change was made in Python as per that bug may have
> solved the problem for one single person, but has screwed up things
> for everyone doing embedded systems where they don't have any control
> over what the master executable links, in this case Apache. Thus, is a
> bit disappointing that they didn't think of the wider impacts of the
> change. Unfortunately it is highly unlikely that Python will now ever
> be changed back to how it was.
>
> Graham

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to modwsgi@googlegroups.com.
To unsubscribe from this group, send email to 
modwsgi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to