Bugzilla Bug 159313

I'd like to see two enhancements to the yacas ebuild:

1. Add a USE flag so it can build the "Proteus" GUI. This has a dependency on
"fltk". The configure option is "--enable-proteus"

2. Add a USE flag so it can build as a server. The configure option is
"--enable-server". The R package "Ryacas", which interfaces to Yacas from R,
appears to be using the server version.

I'm testing all of this from the raw source ... I'll post the results here when
I get the R interface working.

It turns out that if you install yacas from the upstream source, it croaks
building the OpenGL plugin. So does the ebuild, if you have the "glut" USE flag
enabled. So I looked at the ebuild, and there is a hack in there to disable the
opengl plugin if you *don't* have the glut USE flag! This is an upstream bug,
so I don't see much point in filing it here. I did join the yacas mailing list
and posted it there, however. I'm guessing whoever made the Gentoo ebuild ran
into this and made the hack, but I haven't read the Changelog. :)

Well ... it turns out the upstream build croaks with "--enable-proteus" the
same way it croaks with the default "opengl":

make[2]: Entering directory `/home/Software/yacas-build/proteus'
source='../../yacas-1.0.62/proteus/tabs.cpp' object='tabs.o' libtool=no \
        depfile='.deps/tabs.Po' tmpdepfile='.deps/tabs.TPo' \
        depmode=gcc3 /bin/sh ../../yacas-1.0.62/depcomp \
        g++ -DHAVE_CONFIG_H -I. -I../../yacas-1.0.62/proteus -I..
-I/usr/include/fltk-1.1 -I/usr/include/freetype2 -O2 -march=pentium3 -pipe
-fomit-frame-pointer -I../../yacas-1.0.62/src
-I../../yacas-1.0.62/src/plat/linux32/ -DSYSCONFDIR=\"/usr/local/etc\"    -O2
-march=pentium3 -pipe -fomit-frame-pointer -Wall  -c -o tabs.o `test -f
'../../yacas-1.0.62/proteus/tabs.cpp' || echo
'../../yacas-1.0.62/proteus/'`../../yacas-1.0.62/proteus/tabs.cpp
/usr/include/fltk-1.1/FL/Fl_Image.H: In constructor
'Fl_RGB_Image::Fl_RGB_Image(const uchar*, int, int, int, int)':
/usr/include/fltk-1.1/FL/Fl_Image.H:95: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../yacas-1.0.62/src/grower.h: At global scope:
../../yacas-1.0.62/src/grower.h:29: warning: 'class ArrOps' has virtual
functions but non-virtual destructor
../../yacas-1.0.62/proteus/tabs.cpp: In function 'void
LispNotepadAddCommand(LispEnvironment&, int)':
../../yacas-1.0.62/proteus/tabs.cpp:444: error: 'class LispString' has no
member named 'String'

This is the same error that's killing the build with "opengl". It's tough to
see with all of the warnings. 

So for now, I guess the only thing to do to the ebuild is allow the server
option and mark the package as "unstable" with the "glut" USE flag turned on.
:(

I'll add a comment as soon as I hear from the yacas-devel mailing list about
this.

I have at least one fix -- I'm testing it now. According to the yacas-devel
mailing list, there were some changes from 1.0.61 to 1.0.62 that messed this
up. But it's definitely upstream. I may drop back to 1.0.61 just to see if that
builds all the way.

i have same problem of comment#2

(In reply to comment #4)
> i have same problem of comment#2
> 

Yeah ... there are a couple of bugs upstream. I have a workaround that allows
OpenGL and "--enable-server" to compile, but the Proteus piece is a lot more
complicated. I'll go ahead and file a formal bug report upstream; so far I've
gotten workarounds from the yacas-devel mailing list but it's just me and one
of the upstream developers talking -- I haven't seen anyone else chime in and
say anything about getting things changed in the repository or getting the
complicated bug fixed.

Summary of the status:

1. 1.0.62 is no worse that 1.0.61. It may be better, but "dropping back to
1.0.61" doesn't seem to solve anything.

2. The package should probably be masked and/or moved to the "science" overlay
until the upstream source gets fixed.

OK ... looks like we are ready to make this a "real" enhancement bug! :) From
the yacas-devel email list:

Hi,
A new release 1.0.63 is available. This is mostly a maintenance  
release (fixing compilation problems on various platforms).

If any one has a Windows build for me I can place it on my account...
Ayal

---------------------------------------------------------------------------
So, let's change this to

1. Version bump to 1.0.63. Tarball is at
http://yacas.sourceforge.net/backups/yacas-1.0.63.tar.gz

2. Add a local USE flag "proteus" which adds "--enable-proteus" to the
configure step. This one has a dependency on "fltk", so the ebuild would need
to deal with that.

3. Add a local USE flag "yacas-server" which adds "--enable-server" to the
configure step.

I've got the source file and will be testing it momentarily. I'll post the
results to this bug.

Created an attachment (id=105933) [details]
yacas internal check logs for Yacas 1.0.63

I just downloaded and built Yacas 1.0.63 from
http://yacas.sourceforge.net/backups/yacas-1.0.63.tar.gz on my Gentoo system
(Pentium 3 if that matters). Everything looks good and it passed all 45 of its
internal checks. I think 1.0.63 is good to go; I still need to test it with
Ryacas but that shouldn't show anything broken.

If I get the chance, I'll try to make a 1.0.63 ebuild from the existing 1.0.62
ebuild later today. If not, it will be next weekend before I have another
opportunity to play with it.

Thanks a bunch for keeping us up to date on this!
I will try to have a look at yacas next week or at least
by next weekend myself.

cheers,
Markus

Hi guys,

I've just committed a yacas-1.0.63 ebuild that includes the proteus and server
useflags. Everything seems to work fine here apart from a problem with
-as-needed as LDFLAG which I yet have to track down.

Please let me know if there are any other issues and thanks 
much for your help.

Best,
Markus

Hi,

I've just disabled the proteus useflag since after some more testing
the fltk GUI turned out to be very unstable. I wasn't able to enter
data and could trigger random segfaults. Anybody else
experienced the same issues?

Thanks,
Markus