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.