On Mar 28, 9:17 pm, William Stein <wst...@gmail.com> wrote:
> On Sat, Mar 28, 2009 at 9:12 PM, mabshoff <mabsh...@googlemail.com> wrote:

<SNIP>

> > I also looked athttp://wiki.sagemath.org/freebsd/sage-3.4and I am
> > dubious about some of the patches, especially about most of the bits
> > from ports. I did not need any of those to build Sage 3.2 on FreeBSD 7
> > (or I did reproduce some of them :)), but I would recommend that those
> > fixes are pushed upstream. The choice of using shar as an archive
> > format also seems rather strange to me.
>
> > Which java are you using?
>
> Just for the record, I claim that java is not used one spec anywhere
> in the entire Sage test suite.

Yep, we discussed this over lunch. When I was doctesting with FreeBSD
7 and the SunJDK that ran via the linux emulation layer things went
pretty badly.

> The only way Sage uses java is for embedded 3d plotting in the
> notebook or popup 3d plotting in the command line.  Sage doesn't use
> java anywhere else.  I think the 3d doctests just generate the code
> that would get sent to jmol to draw the image, but jmol itself isn't
> actived (since if it were, doctesting any 3d file would take a _long_
> time and involve windows popping up all over the place).
>
>  -- William

Re putchar(): I have this patch for gcc 4.3 on Solaris in tree:

--- pprdrv_tt2.cpp.orig 2009-01-19 06:37:37.373517000 -0500
+++ pprdrv_tt2.cpp      2009-01-19 06:38:26.782530000 -0500
@@ -104,7 +104,8 @@
        {                               /* have a log of points. */
        if(stack_depth == 0)
            {
-           stream.putchar('{');
+            //  Note the below is a hack to make it compile on
Solaris 10 with gcc 4.3.2
+            stream.puts("{");
            stack_depth=1;
            }

It will likely fix the issue you are seeing on FreeBSD 8 + gcc 4.3,
too. I did take a closer look at the patch set you provided and I want
to make a couple remarks:

 * you are patching files like configure scripts and you really should
not do that :)
 * most of the fixes should be pushed upstream
 * I did the build on a 32 bit FreeBSD 7 box, but I can see how some
of the fixes will only be needed for FreeBSD 8 or FreeBSD on x86-64

I think the first step would be to provide individual patches so that
we can decide what to integrate and what to leave out. Some of the
fixes should certainly go in while I cam quite dubious about others,
but we can do that on a case by case review.

Cheers,

Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to