Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: RELEASED Python 2.4, alpha 1

Reply
Thread Tools

Re: RELEASED Python 2.4, alpha 1

 
 
Paul Moore
Guest
Posts: n/a
 
      07-11-2004
[For some reason, this posting never appeared. Here's another try -
apologies if it appears twice]

"Terry Reedy" <(E-Mail Removed)> writes:

>> I don't think anybody has demonstrated yet that you can actually build
>> extensions with the Microsoft compiler that is free of charge.

>
> Which means that reports on experiments attempting to do so would be a
> service to the community


Hmm. I have just done some basic experimentation.

I have 4 C compilers installed, on Windows XP Pro.

1. Microsoft Visual C++ 6
2. Mingw
3. Microsoft .NET SDK (non-optimising C compiler)
4. Microsoft Visual C++ Toolkit 2003

I do not have Visual Studio .NET (any version) installed.

Of these, (1) is not suitable for building extensions for the
python.org Python 2.4, because of CRT differences (as we know).

Also, (4) is not suitable, as it only supports static libraries for
the CRT, and hence not msvcr71.

As I've reported, (a suitably recent version of) mingw works (with a
patch to distutils).

The remaining option is (3). This can build msvcr71-compatible DLLs,
and so should be an option.

I set up my environment to point to the .NET SDK (so that the cl
command executes the .NET SDK compiler). Then, I tried python setup.py
build on a small extenson I had to hand. The result was that I got the
following error:

error: Python was built with version 7.1 of Visual Studio, and
extensions need to be built with the same version of the compiler, but
it isn't installed.

Apparently, distutils is looking in the registry, and finding MSVC6 (I
know it does this, as it can build with an installed Visual Studio
even if the environment variables are not set up). It does not,
apparently, notice that the PATH includes a later "cl" command, which
is suitable.

So, it seems that as things stand, distutils can only build extensions
compatible with the standard python 2.4 distribution, using Visual
Studio .NET 2003, or with mingw (using my patch).

I'm reluctant to try fixing distutils to accept the .NET SDK compiler,
as I can't verify that any changes I make won't break VS.NET 2003
compatibility (as I don't have that compiler).

I hope this is of some use.

Paul.
--
A little inaccuracy sometimes saves tons of explanation -- Saki
 
Reply With Quote
 
 
 
 
Mike C. Fletcher
Guest
Posts: n/a
 
      07-12-2004
Paul Moore wrote:

>"Terry Reedy" <(E-Mail Removed)> writes:
>
>
>>>I don't think anybody has demonstrated yet that you can actually build
>>>extensions with the Microsoft compiler that is free of charge.
>>>
>>>

>>Which means that reports on experiments attempting to do so would be a
>>service to the community
>>
>>

>
>Hmm. I have just done some basic experimentation.
>
>

....

>4. Microsoft Visual C++ Toolkit 2003
>
>

....

>Also, (4) is not suitable, as it only supports static libraries for
>the CRT, and hence not msvcr71.
>
>

Where did you find this out? The installation includes msvcr71.dll,
though that may very well just be because the tools themselves require
it. The options the compiler prints on the command-line seem to suggest
that it can link against msvcrt.dll (which I gather would be msvcr71 in
the new version).

>So, it seems that as things stand, distutils can only build extensions
>compatible with the standard python 2.4 distribution, using Visual
>Studio .NET 2003, or with mingw (using my patch).
>
>

Sigh. Yes, at the very least there will need to be some tweaks there.

>I hope this is of some use.
>
>

Well, at the very least it is making me plan to spend more time working
on Python 2.4 migration than I'd previously thought.

Thanks,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

 
Reply With Quote
 
 
 
 
Mike C. Fletcher
Guest
Posts: n/a
 
      07-12-2004
Mike C. Fletcher wrote:
....

> Where did you find this out? The installation includes msvcr71.dll,
> though that may very well just be because the tools themselves require
> it. The options the compiler prints on the command-line seem to
> suggest that it can link against msvcrt.dll (which I gather would be
> msvcr71 in the new version).


Okay, I've just built mxTextTools 2.1 with the non-recursive extensions,
and SimpleParse is able to run its entire test suite under Python 2.4a1
without errors using it, so at the very least things look promising.
There were a *large* number of warnings about soon-to-be-obsolete and/or
unrecognised flags during the compilation, but nothing that actually
stopped the compile.

I haven't tried uninstalling a Visual Studio 6.0 install on the same
machine to see if that makes a difference, but the compile is definitely
using the VC Toolkit compiler and linker, and the Platform SDK include
and lib directories.

Building Numpy, so far, has failed with:

Creating library build\temp.win32-2.4\Release\Src\_numpy.lib and
object build\temp.win32-2.4\Release\Src\_numpy.exp
arrayobject.obj : error LNK2019: unresolved external symbol __ftol2
referenced in function _FLOAT_to_CHAR

I can't find any reference in Python, Numpy, the Platform SDK or the VC
Toolkit to _FLOAT_to_CHAR. I can only imagine that someone is playing
macro tricks to construct it from something else, I just don't know
where those tricks are.

Have been able to build a few other trivial extensions as well, nothing
that wouldn't have worked with MingW32, though. Real test will be C++
extensions (and, of course, PyOpenGL, which *should* be fine with Ming,
but isn't).

I had to do some (rather ugly) hacking around in msvccompiler to get
past it's insistence on registry variables for everything (the VC
Toolkit doesn't seem to use the registry for storing configuration
directories), and to teach it how to access the Platform SDK (though I'm
not sure why it needs that).

Anyway, for now I need to get to bed, so I suppose I'll pick this up
some other day. Main message is, don't discount the possibility of
building with the Toolkit just yet. Have fun,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

 
Reply With Quote
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      07-12-2004
Mike C. Fletcher wrote:
> Anyway, for now I need to get to bed, so I suppose I'll pick this up
> some other day. Main message is, don't discount the possibility of
> building with the Toolkit just yet. Have fun,


Can you check what CRT your extension modules are linked with?
You can use depends.exe or dumpbin.exe /all to find out.

Python might seriously break if you combine different versions
of the CRT, so you really need to link with msvcr71.dll: not
msvcrt.dll, not crtdll.dll, and not msvcrt40.dll (and neither
msvcr70.dll). Linking with a static libc.lib is also incorrect.

Regards,
Martin

 
Reply With Quote
 
Paul Moore
Guest
Posts: n/a
 
      07-12-2004
"Mike C. Fletcher" <(E-Mail Removed)> writes:

> I haven't tried uninstalling a Visual Studio 6.0 install on the same
> machine to see if that makes a difference, but the compile is
> definitely using the VC Toolkit compiler and linker, and the Platform
> SDK include and lib directories.


The VC Toolkit is definitely wrong, as it doesn't support the DLL
version of the CRT, only the static one. So as Martin points out,
there is a possibility of crashes as a result of CRT
incompatibilities.

Paul
--
A little inaccuracy sometimes saves tons of explanation -- Saki
 
Reply With Quote
 
Paul Moore
Guest
Posts: n/a
 
      07-12-2004
"Mike C. Fletcher" <(E-Mail Removed)> writes:

> Paul Moore wrote:


>>Also, (4) is not suitable, as it only supports static libraries for
>>the CRT, and hence not msvcr71.
>>
>>

> Where did you find this out?


It's documented (albeit not too clearly - you'd think MS didn't want
you to realise there were limitations ) on the website for the
toolkit.

> The installation includes msvcr71.dll, though that may very well
> just be because the tools themselves require it. The options the
> compiler prints on the command-line seem to suggest that it can link
> against msvcrt.dll (which I gather would be msvcr71 in the new
> version).


IIRC, I tried it a while back, and /MD either fails (option not
supported) or uses MSVCRT.

You can check by looking at the import table of the generated EXE -
either use dumpbin from VC6 or objdump -p from mingw.

Paul
--
The only reason some people get lost in thought is because it's
unfamiliar territory -- Paul Fix
 
Reply With Quote
 
Mike C. Fletcher
Guest
Posts: n/a
 
      07-12-2004
Martin v. L÷wis wrote:

> Mike C. Fletcher wrote:
>
>> Anyway, for now I need to get to bed, so I suppose I'll pick this up
>> some other day. Main message is, don't discount the possibility of
>> building with the Toolkit just yet. Have fun,

>
>
> Can you check what CRT your extension modules are linked with?
> You can use depends.exe or dumpbin.exe /all to find out.
>
> Python might seriously break if you combine different versions
> of the CRT, so you really need to link with msvcr71.dll: not
> msvcrt.dll, not crtdll.dll, and not msvcrt40.dll (and neither
> msvcr70.dll). Linking with a static libc.lib is also incorrect.


Well, isn't that a PITA. The MS Toolkit compiler is linking against
msvcrt.dll, not msvcr71.dll. Apparently it's picking up the Visual
Studio 6.0 msvcrt.lib which is then pointing it to the wrong DLL, while
the free compiler and the SDK do not include msvcrt.lib . Okay,
searching about, I find that there's apparently a legal source for
msvcrt.lib, namely the .NET Framework SDK...

http://sapdb.2scale.net/moin.cgi/MS_20C_2b_2b_20Toolkit

So, I take a few minutes to download that (it's only 100MB or so)...
Then add the lib directory to my vc7.bat file's lib environmental
parameter...
And rebuild...

And now depends says the module is linked against msvcr71.dll . There
are apparently other missing headers/libs for the MS Toolkit compiler
(see link above), but I'll plan to cross those bridges when I have more
time for bridge-building .

Have fun,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RELEASED Python 2.4, alpha 3 Anthony Baxter Python 0 09-03-2004 08:36 AM
Re: RELEASED Python 2.4, alpha 2 Anthony Baxter Python 29 08-11-2004 02:07 AM
Re: [Python-Dev] RELEASED Python 2.4, alpha 2 =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Python 9 08-10-2004 04:33 PM
RELEASED Python 2.4, alpha 2 Anthony Baxter Python 0 08-05-2004 01:10 PM
RELEASED Python 2.4, alpha 1 Anthony Baxter Python 22 07-16-2004 07:29 PM



Advertisments