question about building from source on windows

Community matplotlib-users
1

Well, the good news is that I was able to get it to compile and run the wxPython backend on Windows. The bad news is that my symptoms are different enough from yours that I'm not sure this will help you.

I started with a reasonably clean Windows XP SP2 machine with no development tools on it. I installed (using the standard binary installers) the most recent stable releases of the following:

- Python 2.5.1 (python.org)
- wxPython-2.8.4.0
- numpy-1.0.3
- MinGW-5.1.3 (selecting the "current" release option)
- MSys-1.0.10

I checked out the latest matplotlib from svn (r3662).

I downloaded and uncompressed win32_static from here: http://matplotlib.sourceforge.net/win32_static.tar.gz

I did not do the pexports step, as I don't think MinGW requires it any longer.

I updated profile24.bat to point at my new Python 2.5 (this should probably be added to win32_static when someone gets a chance).

I then built and installed using:

python setup.py build --compiler=mingw32 install

(Note that I didn't build and use the Windows installer as the instructions suggest -- I doubt that makes a difference, though).

It built fine the first time.

Then I ran into problems. When importing certain extension modules (ft2font, _transforms etc.), but not others (ttconv), I got a dialog with the error message:

  "The procedure entry point _ctype could not be located in
the dynamic link library msvcr71.dll"

...and then the module would fail to load.

This is quite different from what William was seeing, since for him the modules were obviously loading and then failing in the initialization code.

Googling tells me that this is because libstdc++ (specifically the <string> and <iostream> stuff) depends on _ctype for determining the types of various ASCII characters, which was in msvcrt.dll but was removed from msvcrt71.dll. Python2.5 is built with and therefore requires its extensions to link to msvcrt71.dll, so that's what you get by default. Fortunately, it doesn't seem to hurt to link to both. I added the following to setup.py, right before the final "distrib = setup(..." section:

    from setupext import get_win32_compiler
    if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
        for module in ext_modules:
            module.libraries.append("msvcrt")

After this change, I was able to run embedding_in_wx4.py and get a window with a plot in it. Everything *seems* to be in order.

William, I'm really curious if the above fix solves your problem. I probably shouldn't spend too much more time on this myself, as Windows isn't a very common platform for us (by that I mean my employer, STScI, not matplotlib as a whole). If I can admit selfishness, I really just wanted to make sure I hadn't hosed anything with my recent setup.py changes. I think that has been ruled out, and instead we now have what looks like a big amorphous configuration-difference problem.

Cheers,
Mike

2

Thanks again for all your work on this. I moved my old minGW and installed MinGW-5.1.3, and was already running the others–except numpy, I have the latest version from svn, which I compiled and built fine after building atlas. I checked out matplotlib from svn and did the same as you

–I didn’t try using the importlib batch file–I have a libpython25.a–so, after changing the profile24.bat to profile25.bat with appropriate path changes and your modifications to setup.py, I built it. I then installed it–no problems yet. I then tried to use it with embedding_in_wx4.py and python crashes and burns. I find that it crashes with the same LazyValue error. Something similar happened to one of my colleagues who tried building with visual studio instead of mingw. He’s given up and is now running it on his Mac. Sadly, I don’t have that option. Does anyone else have any ideas?

Thanks,
William

···

On 8/2/07, Michael Droettboom <mdroe@…86…> wrote:

Well, the good news is that I was able to get it to compile and run the wxPython backend on Windows. The bad news is that my symptoms are different enough from yours that I’m not sure this will help you.

I started with a reasonably clean Windows XP SP2 machine with no development tools on it. I installed (using the standard binary installers) the most recent stable releases of the following:

  • Python 2.5.1 (python.org)
  • wxPython-2.8.4.0
  • numpy-1.0.3
  • MinGW-5.1.3 (selecting the “current” release option)
  • MSys-1.0.10

I checked out the latest matplotlib from svn (r3662).

I downloaded and uncompressed win32_static from here: http://matplotlib.sourceforge.net/win32_static.tar.gz

I did not do the pexports step, as I don’t think MinGW requires it any longer.

I updated profile24.bat to point at my new Python 2.5 (this should probably be added to win32_static when someone gets a chance).

I then built and installed using:

python setup.py build --compiler=mingw32 install

(Note that I didn’t build and use the Windows installer as the instructions suggest – I doubt that makes a difference, though).

It built fine the first time.

Then I ran into problems. When importing certain extension modules (ft2font, _transforms etc.), but not others (ttconv), I got a dialog with the error message:

“The procedure entry point _ctype could not be located in
the dynamic link library msvcr71.dll”

…and then the module would fail to load.

This is quite different from what William was seeing, since for him the modules were obviously loading and then failing in the initialization code.

Googling tells me that this is because libstdc++ (specifically the and stuff) depends on _ctype for determining the types of various ASCII characters, which was in msvcrt.dll but was removed from msvcrt71.dll. Python2.5 is built with and therefore requires its extensions to link to msvcrt71.dll, so that’s what you get by default. Fortunately, it doesn’t seem to hurt to link to both. I added the following to setup.py, right before the final “distrib = setup(…” section:

from setupext import get_win32_compiler
if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
    for module in ext_modules:

        module.libraries.append("msvcrt")

After this change, I was able to run embedding_in_wx4.py and get a window with a plot in it. Everything seems to be in order.

William, I’m really curious if the above fix solves your problem. I probably shouldn’t spend too much more time on this myself, as Windows isn’t a very common platform for us (by that I mean my employer, STScI, not matplotlib as a whole). If I can admit selfishness, I really just wanted to make sure I hadn’t hosed anything with my recent setup.py changes. I think that has been ruled out, and instead we now have what looks like a big amorphous configuration-difference problem.

Cheers,
Mike

3

Charlie Moad does our win32 builds for releases -- Charlie if you get
a minute could you see if your build pipeline is still working OK with
the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you *need* to be building from src William?

Thanks,
JDH

···

On 8/2/07, william ratcliff <william.ratcliff@...287...> wrote:

Thanks again for all your work on this. I moved my old minGW and installed
MinGW-5.1.3, and was already running the others--except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas. I checked out matplotlib from svn and did the same as you
--I didn't try using the importlib batch file--I have a libpython25.a--so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it. I then installed
it--no problems yet. I then tried to use it with embedding_in_wx4.py and
python crashes and burns. I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw. He's given up and is now running it on
his Mac. Sadly, I don't have that option. Does anyone else have any ideas?

4

One of my colleagues, Paul Kienzle has made a number of additions to matplotlib for interacting with artists. I need to use some of those additions–which are not included in the stable release. Paul’s on vacation, so I am trying to start from source.

Thanks,
William

···

On 8/2/07, John Hunter <jdh2358@…287…> wrote:

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

Thanks again for all your work on this. I moved my old minGW and installed
MinGW-5.1.3
, and was already running the others–except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas. I checked out matplotlib from svn and did the same as you
–I didn’t try using the importlib batch file–I have a libpython25.a–so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it. I then installed
it–no problems yet. I then tried to use it with embedding_in_wx4.py and

python crashes and burns. I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw. He’s given up and is now running it on

his Mac. Sadly, I don’t have that option. Does anyone else have any ideas?

Charlie Moad does our win32 builds for releases – Charlie if you get
a minute could you see if your build pipeline is still working OK with

the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you need to be building from src William?

Thanks,
JDH

5

Oh–sorry I didn’t read carefully–I don’t need to install from source if there is a binary of the current svn version.

Thanks!!

William

···

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

One of my colleagues, Paul Kienzle has made a number of additions to matplotlib for interacting with artists. I need to use some of those additions–which are not included in the stable release. Paul’s on vacation, so I am trying to start from source.

Thanks,
William

On 8/2/07, John Hunter < > jdh2358@…287…> wrote:

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

Thanks again for all your work on this. I moved my old minGW and installed

MinGW-5.1.3
, and was already running the others–except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas. I checked out matplotlib from svn and did the same as you

–I didn’t try using the importlib batch file–I have a libpython25.a–so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it. I then installed
it–no problems yet. I then tried to use it with embedding_in_wx4.py and

python crashes and burns. I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw. He’s given up and is now running it on

his Mac. Sadly, I don’t have that option. Does anyone else have any ideas?

Charlie Moad does our win32 builds for releases – Charlie if you get
a minute could you see if your build pipeline is still working OK with

the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you need to be building from src William?

Thanks,
JDH

6

One more datapoint–I am becoming suspicious that this could be an arch
problem. A colleague was able to build from source under cygwin
on his rather old laptop. However, another colleague and myself
have rather new computers and both failed (with different errors in the
verbose mode). I just tried following Michael’s build
instructions (incidentally, could his last additions to setup.py be
checked in to svn, along with a profile25.bat file?) on an old windows
box that we have lying around here and it also worked well and I was
able to run the embedding_in_wx4.py example without any problems.

The computer that I’ve been having all of the problems on also was
relatively clean–so, there are only two things I can think of–either
some bizarre clash with the version of numpy that I built from source
off of svn (which passed all of its tests, so I doubt it), or an arch
dependence. I have an intel quad and my colleage has a duo, so
perhaps there’s a problem with computers with multiple
processors? I will check the numpy issue later today.

Thanks again,
William

···

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

Oh–sorry I didn’t read carefully–I don’t need to install from source if there is a binary of the current svn version.

Thanks!!

William

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

One of my colleagues, Paul Kienzle has made a number of additions to
matplotlib for interacting with artists. I need to use some of
those additions–which are not included in the stable release.
Paul’s on vacation, so I am trying to start from source.

Thanks,
William
On 8/2/07, John Hunter < > > > > jdh2358@…287…> wrote:

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

Thanks again for all your work on this. I moved my old minGW and installed

MinGW-5.1.3
, and was already running the others–except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas. I checked out matplotlib from svn and did the same as you

–I didn’t try using the importlib batch file–I have a libpython25.a–so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it. I then installed
it–no problems yet. I then tried to use it with embedding_in_wx4.py and

python crashes and burns. I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw. He’s given up and is now running it on

his Mac. Sadly, I don’t have that option. Does anyone else have any ideas?

Charlie Moad does our win32 builds for releases – Charlie if you get
a minute could you see if your build pipeline is still working OK with

the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you need to be building from src William?

Thanks,
JDH

7

No, with whatever is in the current version of svn, it now works on the intel quad as well. Thanks!

···

On 8/5/07, william ratcliff < william.ratcliff@…287…> wrote:

One more datapoint–I am becoming suspicious that this could be an arch
problem. A colleague was able to build from source under cygwin
on his rather old laptop. However, another colleague and myself
have rather new computers and both failed (with different errors in the
verbose mode). I just tried following Michael’s build
instructions (incidentally, could his last additions to setup.py be
checked in to svn, along with a profile25.bat file?) on an old windows
box that we have lying around here and it also worked well and I was
able to run the embedding_in_wx4.py example without any problems.

The computer that I’ve been having all of the problems on also was
relatively clean–so, there are only two things I can think of–either
some bizarre clash with the version of numpy that I built from source
off of svn (which passed all of its tests, so I doubt it), or an arch
dependence. I have an intel quad and my colleage has a duo, so
perhaps there’s a problem with computers with multiple
processors? I will check the numpy issue later today.

Thanks again,

William

On 8/2/07, william ratcliff < > william.ratcliff@…287…> wrote:

Oh–sorry I didn’t read carefully–I don’t need to install from source if there is a binary of the current svn version.

Thanks!!

William

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

One of my colleagues, Paul Kienzle has made a number of additions to
matplotlib for interacting with artists. I need to use some of
those additions–which are not included in the stable release.
Paul’s on vacation, so I am trying to start from source.

Thanks,
William
On 8/2/07, John Hunter < > > > > > > > > > jdh2358@…287…> wrote:

On 8/2/07, william ratcliff <william.ratcliff@…287…> wrote:

Thanks again for all your work on this. I moved my old minGW and installed

MinGW-5.1.3
, and was already running the others–except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas. I checked out matplotlib from svn and did the same as you

–I didn’t try using the importlib batch file–I have a libpython25.a–so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it. I then installed
it–no problems yet. I then tried to use it with embedding_in_wx4.py and

python crashes and burns. I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw. He’s given up and is now running it on

his Mac. Sadly, I don’t have that option. Does anyone else have any ideas?

Charlie Moad does our win32 builds for releases – Charlie if you get
a minute could you see if your build pipeline is still working OK with

the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you need to be building from src William?

Thanks,
JDH

8

william ratcliff wrote:
> No, with whatever is in the current version of svn, it now works on the
> intel quad as well. Thanks!

That's great news! While it's great to hear that it's working, it would be even better to track down the cause of the failure, if possible.

Do you mean the current version of SVN of numpy or matplotlib? It doesn't like there were any commits to matplotlib over the weekend.

Do you happen to know what SVN revision was breaking before you updated and everything worked? When you finally updated and things worked, did you clean the build directory by any chance? Python distutils doesn't always track dependencies correctly and rebuild enough stuff, which can sometimes be the cause of problems.

    I just tried following Michael's build
    instructions (incidentally, could his last additions to setup.py be
    checked in to svn, along with a profile25.bat file?)

I was wary of committing that change until it had been reviewed by someone else with more mingw32 experience. It worked for me, but it has the feel of something slightly hackish...

For review, in case some other Windows guys are listening, I adding the following right before the final "distrib = setup(..." in setup.py:

     from setupext import get_win32_compiler
     if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
         for module in ext_modules:
             module.libraries.append("msvcrt")

As for profile25.bat, I can't find it in SVN. Maybe whoever is responsible for win32_static.tar.gz needs to do it. Not sure...

Cheers,
Mike

9

I'll give the build a try on windows tonight using my usual methods.

- Charlie

···

On 8/6/07, Michael Droettboom <mdroe@...86...> wrote:

william ratcliff wrote:
> No, with whatever is in the current version of svn, it now works on the
> intel quad as well. Thanks!

That's great news! While it's great to hear that it's working, it would
be even better to track down the cause of the failure, if possible.

Do you mean the current version of SVN of numpy or matplotlib? It
doesn't like there were any commits to matplotlib over the weekend.

Do you happen to know what SVN revision was breaking before you updated
and everything worked? When you finally updated and things worked, did
you clean the build directory by any chance? Python distutils doesn't
always track dependencies correctly and rebuild enough stuff, which can
sometimes be the cause of problems.

> I just tried following Michael's build
> instructions (incidentally, could his last additions to setup.py be
> checked in to svn, along with a profile25.bat file?)

I was wary of committing that change until it had been reviewed by
someone else with more mingw32 experience. It worked for me, but it has
the feel of something slightly hackish...

For review, in case some other Windows guys are listening, I adding the
following right before the final "distrib = setup(..." in setup.py:

     from setupext import get_win32_compiler
     if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
         for module in ext_modules:
             module.libraries.append("msvcrt")

As for profile25.bat, I can't find it in SVN. Maybe whoever is
responsible for win32_static.tar.gz needs to do it. Not sure...

Cheers,
Mike

10

I was using version 3673 of svn (matplotlib) when it worked. I had a clean build directory (I usually kill it before trying to build a new version, along with whatever is in lib/site-packages). I’m not sure of the exact version I was using when it was dying (I want to say somewhere around 3660-69, but I tried a lot last week without success).

Cheers,
William

profile25.bat_text (207 Bytes)

···

On 8/6/07, Michael Droettboom <mdroe@…86…> wrote:

william ratcliff wrote:

No, with whatever is in the current version of svn, it now works on the
intel quad as well. Thanks!

That’s great news! While it’s great to hear that it’s working, it would

be even better to track down the cause of the failure, if possible.

Do you mean the current version of SVN of numpy or matplotlib? It
doesn’t like there were any commits to matplotlib over the weekend.

Do you happen to know what SVN revision was breaking before you updated
and everything worked? When you finally updated and things worked, did
you clean the build directory by any chance? Python distutils doesn’t

always track dependencies correctly and rebuild enough stuff, which can
sometimes be the cause of problems.

I just tried following Michael's build
instructions (incidentally, could his last additions to setup.py be
checked in to svn, along with a profile25.bat file?)

I was wary of committing that change until it had been reviewed by
someone else with more mingw32 experience. It worked for me, but it has

the feel of something slightly hackish…

For review, in case some other Windows guys are listening, I adding the
following right before the final “distrib = setup(…” in setup.py:

 from setupext import get_win32_compiler

 if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
     for module in ext_modules:
         module.libraries.append("msvcrt")

As for profile25.bat, I can’t find it in SVN. Maybe whoever is

responsible for win32_static.tar.gz needs to do it. Not sure…

Cheers,
Mike

11

That message in setupext.py:

  NOTE, if you are building on python24 on win32, see
  os.walk bug?

refers to a patch for distutils to work around that bug. It now
appears this link is stale. Your approach is better anyway, because
it doesn't require patching distutils. I had assumed that because you
guys were following the build instructions closely, that this *was
not* the source of your problems. But it looks like the same bug, or
at least a closely related one. Haven't been able to find an active
link for that post, but your approach probably obviates it anyway.

···

On 8/6/07, Michael Droettboom <mdroe@...86...> wrote:

     from setupext import get_win32_compiler
     if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
         for module in ext_modules:
             module.libraries.append("msvcrt")

12

I got a successful build using VS2003 on Vista. Here is the env dump:

···

============================================================================
BUILDING MATPLOTLIB
            matplotlib: 0.90.1
                python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
                        v.1310 32 bit (Intel)]
              platform: win32
       Windows version: (6, 0, 6000, 2, '')

REQUIRED DEPENDENCIES
                 numpy: 1.0.3
             freetype2: found, but unknown version (no pkg-config)

OPTIONAL DEPENDENCIES
                  Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
                        pygobject: 2.12.3
               Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
              wxPython: no
                        * wxPython not found
                    Qt: no
                   Qt4: no
                 Cairo: 1.2.6
                libpng: found, but unknown version (no pkg-config)

[Edit setup.cfg to suppress the above messages]

And here is the patch to make it work:

Index: C:/workspace/matplotlib/setupext.py

--- C:/workspace/matplotlib/setupext.py (revision 3677)
+++ C:/workspace/matplotlib/setupext.py (working copy)
@@ -676,10 +676,10 @@
     if sys.platform=='win32':
         major, minor1, minor2, s, tmp = sys.version_info
         if major==2 and minor1 in [3, 4, 5]:
- module.include_dirs.extend(['win32_static/include/tcl84'])
+ module.include_dirs.extend(['win32_static/include/tcl8.4'])
             module.libraries.extend(['tk84', 'tcl84'])
         elif major==2 and minor1==2:
- module.include_dirs.extend(['win32_static/include/tcl83'])
+ module.include_dirs.extend(['win32_static/include/tcl8.3'])
             module.libraries.extend(['tk83', 'tcl83'])
         else:
             raise RuntimeError('No tk/win32 support for this python
version yet')
Index: C:/workspace/matplotlib/ttconv/ttutil.cpp

--- C:/workspace/matplotlib/ttconv/ttutil.cpp (revision 3677)
+++ C:/workspace/matplotlib/ttconv/ttutil.cpp (working copy)
@@ -32,10 +32,10 @@
   va_start(arg_list, format);
   char buffer[PRINTF_BUFFER_SIZE];

- int size = vsnprintf(buffer, PRINTF_BUFFER_SIZE, format, arg_list);
+ int size = _vsnprintf(buffer, PRINTF_BUFFER_SIZE, format, arg_list);
   if (size >= PRINTF_BUFFER_SIZE) {
     char* buffer2 = (char*)malloc(size);
- vsnprintf(buffer2, size, format, arg_list);
+ _vsnprintf(buffer2, size, format, arg_list);
     free(buffer2);
   } else {
     this->write(buffer);

I don't have time to add the proper #ifdef to the cpp file at this
moment. I can't remember to proper check off the top of my head.
I'll commit the fix to the setupext.py typo.

Did someone want the build? If so, e-mail me and I'll post it somewhere.

- Charlie

13

The build would be nice given the added features in interactivity in matplotlib now. Would it be difficult to make a Windows XP build as well? My current build seems to work–but others might also want one with the latest features.

Thanks,
William

···

On 8/6/07, Charlie Moad <cwmoad@…287…> wrote:

I got a successful build using VS2003 on Vista. Here is the env dump:

============================================================================
BUILDING MATPLOTLIB
matplotlib: 0.90.1
python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
v.1310 32 bit (Intel)]
platform: win32
Windows version: (6, 0, 6000, 2, ‘’)

REQUIRED DEPENDENCIES
numpy: 1.0.3
freetype2: found, but unknown version (no pkg-config)

OPTIONAL DEPENDENCIES
Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
pygobject: 2.12.3

           Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
          wxPython: no
                    * wxPython not found
                Qt: no
               Qt4: no
             Cairo: 1.2.6
            libpng: found, but unknown version (no pkg-config)

[Edit setup.cfg to suppress the above messages]

And here is the patch to make it work:

Index: C:/workspace/matplotlib/setupext.py

— C:/workspace/matplotlib/setupext.py (revision 3677)
+++ C:/workspace/matplotlib/setupext.py (working copy)

@@ -676,10 +676,10 @@
if sys.platform==‘win32’:
major, minor1, minor2, s, tmp = sys.version_info
if major==2 and minor1 in [3, 4, 5]:

  •        module.include_dirs.extend(['win32_static/include/tcl84'])

  •        module.include_dirs.extend(['win32_static/include/tcl8.4'])
       module.libraries.extend(['tk84', 'tcl84'])
   elif major==2 and minor1==2:

  •        module.include_dirs.extend

([‘win32_static/include/tcl83’])

  •        module.include_dirs.extend(['win32_static/include/tcl8.3'])
       module.libraries.extend(['tk83', 'tcl83'])
   else:

       raise RuntimeError('No tk/win32 support for this python

version yet’)
Index: C:/workspace/matplotlib/ttconv/ttutil.cpp

— C:/workspace/matplotlib/ttconv/ttutil.cpp (revision 3677)

+++ C:/workspace/matplotlib/ttconv/ttutil.cpp (working copy)
@@ -32,10 +32,10 @@
va_start(arg_list, format);
char buffer[PRINTF_BUFFER_SIZE];

  • int size = vsnprintf(buffer, PRINTF_BUFFER_SIZE, format, arg_list);
  • int size = _vsnprintf(buffer, PRINTF_BUFFER_SIZE, format, arg_list);
    if (size >= PRINTF_BUFFER_SIZE) {
    char* buffer2 = (char*)malloc(size);
  • vsnprintf(buffer2, size, format, arg_list);

  • _vsnprintf(buffer2, size, format, arg_list);

    free(buffer2);
    } else {
    this->write(buffer);

I don’t have time to add the proper #ifdef to the cpp file at this
moment. I can’t remember to proper check off the top of my head.

I’ll commit the fix to the setupext.py typo.

Did someone want the build? If so, e-mail me and I’ll post it somewhere.

  • Charlie