Re: RELEASED Python 2.4, alpha 1

Discussion in 'Python' started by Mike C. Fletcher, Jul 9, 2004.

  1. I don't see note of switch to Visual Studio .NET for Win32 builds, but
    somehow I'd thought that was planned for the 2.4 timeframe. Did I get
    that wrong? Do we wait for 2.5 for that?

    Itching to be able to use the free compiler to generate PyOpenGL binaries,
    Mike

    Anthony Baxter wrote:

    > On behalf of the Python development team and the Python community, I'm
    > happy to announce the first alpha of Python 2.4.


    ....
    ________________________________________________
    Mike C. Fletcher
    Designer, VR Plumber, Coder
    http://members.rogers.com/mcfletch/
    blog: http://zope.vex.net/~mcfletch/plumbing/
     
    Mike C. Fletcher, Jul 9, 2004
    #1
    1. Advertising

  2. Mike C. Fletcher wrote:
    > I don't see note of switch to Visual Studio .NET for Win32 builds, but
    > somehow I'd thought that was planned for the 2.4 timeframe. Did I get
    > that wrong?


    The Windows binaries are built with VS .NET 2003 indeed (i.e. *not*
    with Visual Studio .NET). It might not have been mentioned, but then,
    it is only one of the many changes, and a comparatively minor one
    (for Windows, using Windows Installer is more significant, as it affects
    more users).

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 9, 2004
    #2
    1. Advertising

  3. Mike C. Fletcher wrote:
    > I don't see note of switch to Visual Studio .NET for Win32 builds, but
    > somehow I'd thought that was planned for the 2.4 timeframe. Did I get
    > that wrong?


    The Windows binaries are built with VS .NET 2003 indeed (i.e. *not*
    with Visual Studio .NET). It might not have been mentioned, but then,
    it is only one of the many changes, and a comparatively minor one
    (for Windows, using Windows Installer is more significant, as it affects
    more users).

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 9, 2004
    #3
  4. =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 9, 2004
    #4
  5. =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 9, 2004
    #5
  6. Martin v. Löwis wrote:

    > Mike C. Fletcher wrote:
    >
    >> I don't see note of switch to Visual Studio .NET for Win32 builds,
    >> but somehow I'd thought that was planned for the 2.4 timeframe. Did
    >> I get that wrong?

    >
    >
    > Actually, it is mentioned in the "What's new" document:
    >
    > http://www.python.org/dev/doc/devel/whatsnew/node9.html#SECTION000910000000000000000
    >


    Well, no ;) :) . What's mentioned there is that it *builds*, not that
    the Python.org installer version *is built* with it, those are two
    different issues, particularly for extension writers, as we target the
    Python.org distributed version almost exclusively. Whether it's
    possible to build Python with a given compiler is an academic question
    if people don't generally have compilers or compile things.

    IMO it's not really a "minor" issue for Windows. It means that (in the
    interim) extension developers need to have both VS6 and VS.NET (2003)
    installed to build for < 2.4 and >=2.4. That's fine (after all, there's
    a free VS.Net version compatible with the new Python IIRC), and I'm all
    for it, but I'd actually consider it a fairly major new feature for a
    platform where previously there's been no freely-available C/C++
    compiler compatible with the current Python build. (Well, save with
    some serious hacking about).

    Have fun,
    Mike

    ________________________________________________
    Mike C. Fletcher
    Designer, VR Plumber, Coder
    http://members.rogers.com/mcfletch/
    blog: http://zope.vex.net/~mcfletch/plumbing/
     
    Mike C. Fletcher, Jul 9, 2004
    #6
  7. Mike C. Fletcher wrote:
    > IMO it's not really a "minor" issue for Windows. It means that (in the
    > interim) extension developers need to have both VS6 and VS.NET (2003)
    > installed to build for < 2.4 and >=2.4. That's fine (after all, there's
    > a free VS.Net version compatible with the new Python IIRC), and I'm all
    > for it, but I'd actually consider it a fairly major new feature for a
    > platform where previously there's been no freely-available C/C++
    > compiler compatible with the current Python build. (Well, save with
    > some serious hacking about).


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

    OTOH, the situation with respect to other compilers hasn't changed
    much: You can build extension modules with mingw32 now roughly as
    easily as you can with earlier Python releases.

    Of course, the change is still important for people who build
    extension modules on Windows: For all practical purposes, they need
    a different Microsoft compiler now.

    However, I still maintain that other changes (e.g. PEP 237) will
    affect way more people.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 9, 2004
    #7
  8. Mike C. Fletcher

    Terry Reedy Guest


    > 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 ;-)

    tjr
     
    Terry Reedy, Jul 10, 2004
    #8
  9. Mike C. Fletcher

    Paul Moore Guest

    "Terry Reedy" <> 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 ;-)


    I haven't had success with the free MS compiler yet, but have built
    extensions successfully with mingw. It needs a patch
    (http://www.python.org/sf/870382) but otherwise works pretty well
    modulo the usual need, documented in the distutils docs, to build
    libpython24.a.

    Paul
    --
    This signature intentionally left blank
     
    Paul Moore, Jul 10, 2004
    #9
  10. Mike C. Fletcher

    Paul Moore Guest

    "Terry Reedy" <> 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
     
    Paul Moore, Jul 10, 2004
    #10
  11. Mike C. Fletcher

    Paul Moore Guest

    [For some reason, this posting never appeared. Here's another try -
    apologies if it appears twice]

    "Terry Reedy" <> 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
     
    Paul Moore, Jul 11, 2004
    #11
  12. Paul Moore wrote:

    >"Terry Reedy" <> 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/
     
    Mike C. Fletcher, Jul 12, 2004
    #12
  13. 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/
     
    Mike C. Fletcher, Jul 12, 2004
    #13
  14. 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
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 12, 2004
    #14
  15. Mike C. Fletcher

    Paul Moore Guest

    "Mike C. Fletcher" <> 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
     
    Paul Moore, Jul 12, 2004
    #15
  16. Mike C. Fletcher

    Paul Moore Guest

    "Mike C. Fletcher" <> 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
     
    Paul Moore, Jul 12, 2004
    #16
  17. 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/
     
    Mike C. Fletcher, Jul 12, 2004
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anthony Baxter

    RELEASED Python 2.4, alpha 1

    Anthony Baxter, Jul 9, 2004, in forum: Python
    Replies:
    22
    Views:
    602
    Irmen de Jong
    Jul 16, 2004
  2. Anthony Baxter

    RELEASED Python 2.4, alpha 2

    Anthony Baxter, Aug 5, 2004, in forum: Python
    Replies:
    0
    Views:
    258
    Anthony Baxter
    Aug 5, 2004
  3. =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

    Re: [Python-Dev] RELEASED Python 2.4, alpha 2

    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 5, 2004, in forum: Python
    Replies:
    9
    Views:
    397
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Aug 10, 2004
  4. Anthony Baxter

    Re: RELEASED Python 2.4, alpha 2

    Anthony Baxter, Aug 5, 2004, in forum: Python
    Replies:
    29
    Views:
    686
    Greg Ewing
    Aug 11, 2004
  5. Anthony Baxter

    RELEASED Python 2.4, alpha 3

    Anthony Baxter, Sep 3, 2004, in forum: Python
    Replies:
    0
    Views:
    321
    Anthony Baxter
    Sep 3, 2004
Loading...

Share This Page