- Python extensions for Windows MUST be linked with the /MD switch to use the multithreaded runtime library. Optimizations are also enabled by the following line:
class MSVCCompiler (CCompiler) : def __init__ (self, [...] self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
- In build_ext.py I find the following code:
def build_extensions (self, extensions): if self.compiler.compiler_type == 'msvc': def_file = build_info.get ('def_file') if def_file is None: source_dir = os.path.dirname (sources[0]) ext_base = (string.split (extension_name, '.'))[-1] def_file = os.path.join (source_dir, "%s.def" % ext_base) if not os.path.exists (def_file): self.warn ("file '%s' not found: " % def_file + "might have problems building DLL") def_file = None
if def_file is not None:
extra_args.append ('/DEF:' + def_file)
Doesn't this belong into msvccompiler.py?
We do not need any stinkin' DEF-files, if we use the link options /EXPORT and /BASE. The following code builds the required arguments:
if def_file is not None:
extra_args.append ('/DEF:' + def_file)
else:
# if no def file is found, export the init<name> function
# and calculate a random base address
extra_args.append ('/EXPORT:init' + extension_name)
import whrandom
base = whrandom.randint (0x1000, 0x8000) * 0x10000
extra_args.append ('/BASE:0x%x' % base)
Regards,
Thomas Heller ION-TOF GmbH
On 13 January 2000, Thomas Heller said:
- Python extensions for Windows MUST be linked with the /MD switch to use the multithreaded runtime library. Optimizations are also enabled by the following line:
class MSVCCompiler (CCompiler) : def __init__ (self, [...] self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
I haven't seen any disagreement with this, so I'll take your word for it. I'd feel more comfortable if another Python/Windows extension developer would speak up and say, "Yep, that's the Right Thing to do". (Mark? Guido?)
So what are the flags here? I assume /Ox is for optimization; you said /MD selects the multithreaded RT library. What is /GD for?
- In build_ext.py I find the following code:
[...code to deal with .def files elided...]
Doesn't this belong into msvccompiler.py?
If anywhere at all. I really, really dislike this whole .def file thing, and I don't like them cluttering up the build options dictionary or the build_ext command class. But I don't know how else to do it, because I know about as much about Python on Windows as I do about skateboarding on Pluto.
We do not need any stinkin' DEF-files, if we use the link options /EXPORT and /BASE. The following code builds the required arguments:
Hallelujah! I've been waiting for someone to say this. Ever since I found out what .def files are, I've been wondering why the heck they are needed.
if
def_file is not None:
extra_args.append ('/DEF:' + def_file)
else:
# if no def file is found, export the init<name> function
# and calculate a random base address
extra_args.append ('/EXPORT:init' + extension_name)
import whrandom
base = whrandom.randint (0x1000, 0x8000) * 0x10000
extra_args.append ('/BASE:0x%x' % base)
But this looks weird: a random base address? What the heck is going on here? Again, could another Python-on-Windows expert speak up? Nothing personal, Thomas, but I don't want to take the word of just one person on this code, and I'd like to know what the heck the random base address is all about.
Thanks for the code -- now let's hear from some other voices as to whether this is the Right Thing to add to Distutils to compile extensions with MSVC. Anyone?
Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
On 13 January 2000, Thomas Heller said:
- Python extensions for Windows MUST be linked with the /MD switch to use the multithreaded runtime library. Optimizations are also enabled by the following line:
class MSVCCompiler (CCompiler) : def __init__ (self, [...] self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
I haven't seen any disagreement with this, so I'll take your word for it. I'd feel more comfortable if another Python/Windows extension developer would speak up and say, "Yep, that's the Right Thing to do". (Mark? Guido?)
So what are the flags here? I assume /Ox is for optimization; you said /MD selects the multithreaded RT library. What is /GD for?
/GD means 'optimize for DLLs'. Not really sure what it does ;-> Oh, shit: Does nothing. MS> /GD (Optimize for Windows DLL) MS> This optimization option is for future use.
>
- In build_ext.py I find the following code:
[...code to deal with .def files elided...]
Doesn't this belong into msvccompiler.py?
If anywhere at all. I really, really dislike this whole .def file thing, and I don't like them cluttering up the build options dictionary or the build_ext command class. But I don't know how else to do it, because I know about as much about Python on Windows as I do about skateboarding on Pluto.
We do not need any stinkin' DEF-files, if we use the link options /EXPORT and /BASE. The following code builds the required arguments:
Hallelujah! I've been waiting for someone to say this. Ever since I found out what .def files are, I've been wondering why the heck they are needed. DEF files define (at least) the exported functions in a DLL. Python extensions usually only export the init<module> function, so this can easily be defined in a linker switch.
>
if def_file is not None:
extra_args.append ('/DEF:' + def_file)
else:
# if no def file is found, export the init<name> function
# and calculate a random base address
extra_args.append ('/EXPORT:init' + extension_name)
import whrandom
base = whrandom.randint (0x1000, 0x8000) * 0x10000
extra_args.append ('/BASE:0x%x' % base)
But this looks weird: a random base address? What the heck is going on
On windows DLLs are linked to a certain start address. The linker uses a default of 0x11000000, if not otherwise specified. The windows loader, when trying to load the DLL, must relocate the DLL to a different address if a conflict occurrs (which is slow). Unless we have a central registry of base adresses for python extensions, we normally cannot avoid these conflicts.
MS says:
# Because there is no way to know what base addresses might be chosen by
other
# in-process components your users might employ, the best practice is to
choose
# an address at random from the indicated range, and round it up to the next
# multiple of 64K.
# If your company produces many in-process components, you may wish
# to randomly calculate the base address of the first, and then arrange
# the others above or below the first, thus guaranteeing at least
# that your company's components will not have memory conflicts.
http://msdn.microsoft.com/library/devprods/vs6/vbasic/vbcon98/vbconsettingba seaddressesforolecontrolprojects.htm
here? Again, could another Python-on-Windows expert speak up? Nothing personal, Thomas, but I don't want to take the word of just one person on this code, and I'd like to know what the heck the random base address is all about. It is a try. At least, if you still support .def files, the module distributor can select: random base address, or using one from a def file. Further info, other possibilities to supply a base address: http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_.2f.base .htm
>
Thanks for the code -- now let's hear from some other voices as to whether this is the Right Thing to add to Distutils to compile extensions with MSVC. Anyone?
Greg
-- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
In article 20000117153950.C9793@cnri.reston.va.us, Greg Ward gward@cnri.reston.va.us writes
On 13 January 2000, Thomas Heller said:
- Python extensions for Windows MUST be linked with the /MD switch to use the multithreaded runtime library. Optimizations are also enabled by the following line:
class MSVCCompiler (CCompiler) : def __init__ (self, [...] self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
I haven't seen any disagreement with this, so I'll take your word for it. I'd feel more comfortable if another Python/Windows extension developer would speak up and say, "Yep, that's the Right Thing to do". (Mark? Guido?)
/GD is for a DLL specific optimisation
>
So what are the flags here? I assume /Ox is for optimization; you said /MD selects the multithreaded RT library. What is /GD for?
- In build_ext.py I find the following code:
[...code to deal with .def files elided...]
Doesn't this belong into msvccompiler.py?
If anywhere at all. I really, really dislike this whole .def file thing, and I don't like them cluttering up the build options dictionary or the build_ext command class. But I don't know how else to do it, because I know about as much about Python on Windows as I do about skateboarding on Pluto.
We do not need any stinkin' DEF-files, if we use the link options /EXPORT and /BASE. The following code builds the required arguments:
Hallelujah! I've been waiting for someone to say this. Ever since I found out what .def files are, I've been wondering why the heck they are needed.
.def files are for exporting things which aren't declared exported in the code. They're not needed if you use the MSVC specific declarators.
>
if def_file is not None:
extra_args.append ('/DEF:' + def_file)
else:
# if no def file is found, export the init<name> function
# and calculate a random base address
extra_args.append ('/EXPORT:init' + extension_name)
import whrandom
base = whrandom.randint (0x1000, 0x8000) * 0x10000
extra_args.append ('/BASE:0x%x' % base)
But this looks weird: a random base address? What the heck is going on here? Again, could another Python-on-Windows expert speak up? Nothing personal, Thomas, but I don't want to take the word of just one person on this code, and I'd like to know what the heck the random base address is all about.
Please don't bother to use random addresses. If you're lucky your build may make a very small difference. Ideally under windows all the dlls needed for a given application should have non intersecting default address ranges. See the file PC/dll_base.txt in the source distribution. However, this is only a minor optimisation and it seems that Guido has abandoned it in favour of simplicity. In a distribution where all the dlls are fixed it might be worth rebasing all of the dlls. The random hack may work, but is not guaranteed to avoid base clashes.
Thanks for the code -- now let's hear from some other voices as to whether this is the Right Thing to add to Distutils to compile extensions with MSVC. Anyone?
Greg
-- Robin Becker
-
Greg Ward -
Robin Becker -
Thomas Heller -
Thomas Heller