When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC
4.3.3, I get an error:
ttconv/pprdrv_tt2.cpp: In member function ‘void
GlyphToType3::stack(TTStreamWriter&, int)’:
ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member
named ‘putc’
So I tried invoking GCC with the -E flag to get the output of the
preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
stream.putc(('{'), (&__iob[1]));
so it seems that something in GCC 4.3.3 on Solaris is defining a putchar
macro that is doing this, but not correspondingly being applied to the
pprdrv.h.
Searching the list archives, I see that back in July & August, 2008
there was a brief thread between Peter Norton and Mike Droettboom about
this and a proposal was made to rename TTStreamWriter::putchar to
TTStreamWriter:put_char. I just looked at the trunk and it looks like
this has never been done. Was there some other work-around that didn't
make it into the thread that obviated the need for the mentioned change?
I can confirm that the renaming of putchar to put_char does solve the
problem. I've attached a patch file, though it is against 0.98.5.2.
-- Dave
Thanks. I have committed this to the 0.98.x branch and the trunk, so
this fix will make it into the next release.
Mike
Dave Peterson wrote:
> When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC
> 4.3.3, I get an error:
>
> ttconv/pprdrv_tt2.cpp: In member function ‘void
> GlyphToType3::stack(TTStreamWriter&, int)’:
> ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member
> named ‘putc’
>
> So I tried invoking GCC with the -E flag to get the output of the
> preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
> stream.putc(('{'), (&__iob[1]));
> so it seems that something in GCC 4.3.3 on Solaris is defining a
> putchar macro that is doing this, but not correspondingly being
> applied to the pprdrv.h.
>
> Searching the list archives, I see that back in July & August, 2008
> there was a brief thread between Peter Norton and Mike Droettboom
> about this and a proposal was made to rename TTStreamWriter::putchar
> to TTStreamWriter:put_char. I just looked at the trunk and it looks
> like this has never been done. Was there some other work-around that
> didn't make it into the thread that obviated the need for the
> mentioned change?
>
> I can confirm that the renaming of putchar to put_char does solve the
> problem. I've attached a patch file, though it is against 0.98.5.2.
>
>
> -- Dave
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...> wrote: > Thanks. I have committed this to the 0.98.x branch and the trunk, so > this fix will make it into the next release. > > Mike Excellent. For the record this is/was also a problem on some FreeBSD releases, so I am glad it was cleanly fixed. I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build fix. Is it still time to get those into 0.98.x? Cheers, Michael
On Thu, Apr 30, 2009 at 4:10 PM, Michael Abshoff <mab...@go...>wrote: > On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...> > wrote: > > Thanks. I have committed this to the 0.98.x branch and the trunk, so > > this fix will make it into the next release. > > > > Mike > > Excellent. For the record this is/was also a problem on some FreeBSD > releases, so I am glad it was cleanly fixed. > > I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build > fix. Is it still time to get those into 0.98.x? There is certainly time to get it into the trunk -- if you want to put it in as a bugfix on the branch, you must be pretty sure that this will not break anything because it is a bugfix release. JDH