Ah, that works now, thanks! That gets me an executable, which if run from
within the Python-2.7.6 directory so it can find Lib/*.py, gives the
following error message:
Traceback (most recent call last):
File ".\lib\site.py", line 548, in <module>
main()
File ".\lib\site.py", line 537, in main
aliasmbcs()
File ".\lib\site.py", line 467, in aliasmbcs
if enc.startswith('cp'): # "cp***" ?
AttributeError: 'NoneType' object has no attribute 'startswith'
The relevant section of site.py is:
if sys.platform == 'win32':
import locale, codecs
enc = locale.getdefaultlocale()[1]
if enc.startswith('cp'): # "cp***" ?
try:
codecs.lookup(enc)
except LookupError:
import encodings
encodings._cache[enc] = encodings._unknown
encodings.aliases.aliases[enc] = 'mbcs'
so it looks like getdefaultlocale is returning blanks. A Google search
suggests it sometimes does this for various reasons; I'm not sure how to
reconcile that with site.py expecting such to never happen, or why it works
in the default DLL build. Any ideas?
On Tue, Jan 21, 2014 at 4:32 PM, Jeremy Kloth <jeremy.kl...@gmail.com>wrote:
> On Tue, Jan 21, 2014 at 5:07 AM, Russell Wallace
> <russell.wall...@gmail.com> wrote:
> > The '...' is the long list of source files I got from pythoncore.vcproj,
> > plus getbuildinfo.c, and the required include directives. You would
> think a
> > missing main function would be the explanation, but the absence of a
> leading
> > _ in the error message is a key indicator. To make sure, I tried adding a
> > main function by hand, and also wmain just in case, and the error still
> > occurs.
>
> The list of files also needs "..\Modules\python.c" to create an
> executable. (tested with VS2008 for x64).
>
> That lack of leading underscore comes from how symbols are exported in
> 64-bit PEs vs. 32-bit PEs. That is, 64-bit PEs do not prepend an
> underscore to exported symbols.
>
> --
> Jeremy Kloth
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
