[Distutils] More (Windows) comments on distutils-0.1.2
Mon, 17 Jan 2000 22:17:02 +0100
> On 13 January 2000, Thomas Heller said:
> > 1. 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.
> > 2. 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
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.
#Because there is no way to know what base addresses might be chosen by
#in-process components your users might employ, the best practice is to
#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.
> 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
can select: random base address, or using one from a def file.
Further info, other possibilities to supply a base address:
> 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 Ward - software developer firstname.lastname@example.org
> 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