Fix matplotlib build on FreeBSD

[peterjeremy]

0. Add support for FreeBSD later than 6.x

1. Explicitly add SAGE_LOCAL to the dependency search path for matplotlib for FreeBSD - superceded by update matplotlib #9202

2. gcc-4.3 on FreeBSD (though not the base gcc4.2) appears to define putchar() in <stdio.h> in a way that breaks the putchar() definitions inside ttconv. It's not immediately clear what the problem is (since there's no immediately obvious difference in the way putchar() is defined in <stdio.h>) so this patch takes
   the easy way out and undef's the offending putchar() macro - no longer needed with gcc-4.5

3. Individual character bounding boxes in AFM files do not have to be integral so convert each bounding box to a list of floats, rather than a list of ints. This corrects a problem where most of the tests would fail with "ValueError: invalid literal for int() with base 10: '539.621'" on FreeBSD - now integrated into matplotlib

Upstream: None of the above - read trac for reasoning.

CC: @jasongrout @sagetrac-stephen

Component: porting: BSD

Reviewer: Stephen Montgomery-Smith, Paul Ivanov

Issue created by migration from https://trac.sagemath.org/ticket/5873

[jasongrout]

comment:1

Attachment: matplotlib-0.98.5.3rc0-svn6910.p3.patch.gz

Of course, this should be added to the current matplotlib spkg.

[peterjeremy]

Attachment: 5873.matplotlib.patch.gz

[peterjeremy]

Author: Peter Jeremy

[peterjeremy]

comment:2

5873.matplotlib.patch has been updated for matplotlib-0.99.1.p2. Of the patches mentioned in the original description, only the first part remains (and is still necessary).

The second part (related to putchar problems with gcc43) has been removed as it's no longer practical to build Sage with gcc43 on FreeBSD.

The third part (related to bounding box conversions) has been removed as an equivalent patch has been integrated into matplotlib-0.99.1

[jasongrout]

comment:3

The matplotlib spkg up at #9202 should take care of the remaining issue in this patch (by prepending the SAGE_LOCAL directory no matter what the platform). Can you check to see if #9202 fixes things?

[sagetrac-drkirkby]

comment:4

Replying to @jasongrout:

The matplotlib spkg up at #9202 should take care of the remaining issue in this patch (by prepending the SAGE_LOCAL directory no matter what the platform). Can you check to see if #9202 fixes things?

Any thoughts about this Peter? I noticed you created (or at least edited) a wiki page about the FreeBSD port, and still reference this old patch, which is probably no longer needed.

Dave

[peterjeremy]

comment:5

Unfortunately, a variant of this patch is still needed to support FreeBSD later than FreeBSD6. Whilst #9202 means prepending SAGE_LOCAL should no longer be necessary, additional OS-related lines are still needed to support recent versions of FreeBSD.

[sagetrac-drkirkby]

comment:6

Replying to @peterjeremy:

Unfortunately, a variant of this patch is still needed to support FreeBSD later than FreeBSD6. Whilst #9202 means prepending SAGE_LOCAL should no longer be necessary, additional OS-related lines are still needed to support recent versions of FreeBSD.

If you wish to create one, I'll try to review it reasonably quickly. It makes review a lot easier if you can include things inside

#ifdef FREEBSD 
#endif

or if appropriate

#ifdef HAVE_BUGGY_GCC_ON_FREEBSD
#undef putchar
#endif

or similar. Otherwise, it requires the reviewer to have a much deeper knowledge of the code to evaluate if the changes are desirable or not. If it can be seen the changes only affect FreeBSD, then it will be much easier to get a positive review. That's been my experience with Solaris and OpenSolaris related problems.

Dave

[peterjeremy]

Attachment: matplotlib-0.99.1.p4.patch.gz

[peterjeremy]

Upstream: Completely fixed; Fix reported upstream

[peterjeremy]

comment:7

Point 0 has been reported upstream as https://sourceforge.net/tracker/?func=detail&aid=3031051&group_id=80706&atid=560722 and an updated patch (not yet converted to spkg) uploaded.

[kcrisman]

comment:8

Replying to @peterjeremy:

Point 0 has been reported upstream as https://sourceforge.net/tracker/?func=detail&aid=3031051&group_id=80706&atid=560722 and an updated patch (not yet converted to spkg) uploaded.

Unfortunately, this link no longer works, as matplotlib has moved its bug tracker to Github. Pleasantly, the ticket is still there. Sadly, the patch appears to have been lost there, though it's still here.

[kcrisman]

comment:9

Apparently Stephen Montgomery-Smith has gotten matplotlib to build fine for Sage in the meantime, or possibly using a system matplotlib.

[kcrisman]

comment:10

More success with this thread. Checking whether system variant or Sage version.

[kcrisman]

Reviewer: Stephen Montgomery-Smith

[kcrisman]

comment:11

Some of the reason this is unnecessary is probably due to the upgrades in gcc.

I don't understand, though, why the patch for newer FreeBSD is no longer necessary. The current mpl source (June 2012) does not have it incorporated.

This is weird enough that I'm not putting positive review; it seems like there should be a key error at this spot if we don't have something in the dictionary for this system.

[kcrisman]

Changed author from Peter Jeremy to none

[sagetrac-pi]

comment:12

I just wanted to chime in with the reason that the patch for newer FreeBSD was not necessary on FreeBSD itself, is because their ports tree incorporates it itself downstream. So that's the reason it is not in the current MPL source (we haven't heard enough people building it natively complain, they were probably using the system variant).

As it stands, either MPL PR #982 or MPL PR #985 will make this a non-issue (and you can grab either of those patches in the meantime, they will both also work for FreeBSD10, and MPL !#985 will work for any other future releases, as well any other POSIX systems that got left out.

[kcrisman]

comment:13

Thanks for this info. Strange, though, because the testing in question was not using the system mpl, as far as I know.

Stephen, any thoughts on this? We could make a custom spkg with one of these patches.

[sagetrac-stephen]

comment:14

I am going to have to say that I don't know why the FreeBSD port of sage doesn't build without this patch. I looked at the FreeBSD port of matplotlib, and this patch was included there. I just don't understand what is going on. Let me look into it some more.

[sagetrac-pi]

comment:15

TLDR: you don't need this patch.

The mpl setupext.py code in question gets used when there is not an entry for basedirlist in setup.cfg, in which case it'll grab it from this pre-defined basedir dictionary using sys.platform as they key. From what I see that's checked into hg for SAGE, you do define basedirlist in setup.cfg, which is why this patch is un-necessary. The code is in the SPKG matplotlib.../make-setup-config.py:7

config.set('directories', 'basedirlist', os.environ['SAGE_LOCAL'])

which is why this patch is not needed for SPKG matplotlib being built on any platform.

From what I understand from the discussion at Python Bug #12326, it seems like we (MPL) should not have been using sys.platform in the first place for making these decisions (but given the somewhat exotic nature of the platforms which have exceptions there now, it's best to remain conservative about re-writing that portion of the code to use something like the platform modules). But to reiterate, the approach taken in the SPKG bypasses this fragility for SAGE that is completely platform independent.

[kcrisman]

Changed upstream from Completely fixed; Fix reported upstream to None of the above - read trac for reasoning.

[kcrisman]

Changed reviewer from Stephen Montgomery-Smith to Stephen Montgomery-Smith, Paul Ivanov

[kcrisman]

comment:16

@sagetrac-pi:
So it sounds like between the practical experience of stephen and the upstream and our config you are pointing out, that we don't have to do anything. Even though eventually mpl will have some other workaround.

If that's correct, I've put what I think is your real name here - just switch to "positive review"! I'm switching the upstream to "none of the above" since this is a somewhat unusual situation. Is this your first contribution? If so, welcome to the Sage team!

[sagetrac-pi]

comment:17

@kcrisman it is my first direct Sage contribution, thanks!

[kcrisman]

comment:18

Great!