On 1 May 2011 15:33, Alejandro <afrit...@gmail.com> wrote:
> 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
Yeah, that is what I meant, not SQLAlchemy. I knew it was database
related, but couldn't remember which.
Anyway, did not know you could embed a manifest file into Apache after
the fact. I'll look through this more properly later when have the
time and inclination and maybe document something about this
procedure.
Thanks.
Graham
> 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.
>
>
--
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.
