Compiling Pytave under Sage

configure:4787: checking whether linking to Octave library works
configure:4822: g++ -o conftest -g -O2 -I/usr/include/octave-3.2.4 -L/usr/lib/octave-3.2.4 conftest.cpp -loctave -lcruft -loctinterp >&5
In file included from /usr/include/octave-3.2.4/octave/oct.h:31,
                 from conftest.cpp:9:
/usr/include/octave-3.2.4/octave/config.h:982:1: warning: "PACKAGE_BUGREPORT" redefined
conftest.cpp:6:1: warning: this is the location of the previous definition
/usr/include/octave-3.2.4/octave/config.h:985:1: warning: "PACKAGE_NAME" redefined
conftest.cpp:2:1: warning: this is the location of the previous definition
/usr/include/octave-3.2.4/octave/config.h:988:1: warning: "PACKAGE_STRING" redefined
conftest.cpp:5:1: warning: this is the location of the previous definition
/usr/include/octave-3.2.4/octave/config.h:991:1: warning: "PACKAGE_TARNAME" redefined
conftest.cpp:3:1: warning: this is the location of the previous definition
/usr/include/octave-3.2.4/octave/config.h:997:1: warning: "PACKAGE_VERSION" redefined
conftest.cpp:4:1: warning: this is the location of the previous definition
/usr/lib/octave-3.2.4/liboctinterp.so: undefined reference to `gzungetc@ZLIB_1.2.0.2'
collect2: ld returned 1 exit status

What does

mkoctfile -p LIBS
mkoctfile -p LDFLAGS

tell you? Please inform me.

Try feeding these values back to configure with ./configure LDFLAGS=... LIBS=...

The result for these commands are :

mkoctfile -p LIBS
     -lreadline -lncurses -ldl -lhdf5 -lz -lm
mkoctfile -p LDFLAGS
     ''

It looks like there the version of zlib used for sage is not the same as
the system one. Does it necessarly mean I need to use system zlib to
compile Sage ? (I tried to remove the zlib files from the Sage
installation and it solved the Octave dependence problem)

Le 11/05/2010 16:52, David Grundberg a écrit :
> configure:4787: checking whether linking to Octave library works
> configure:4822: g++ -o conftest -g -O2 -I/usr/include/octave-3.2.4 -L/usr/lib/octave-3.2.4 conftest.cpp -loctave -lcruft -loctinterp>&5
> In file included from /usr/include/octave-3.2.4/octave/oct.h:31,
> from conftest.cpp:9:
> /usr/include/octave-3.2.4/octave/config.h:982:1: warning: "PACKAGE_BUGREPORT" redefined
> conftest.cpp:6:1: warning: this is the location of the previous definition
> /usr/include/octave-3.2.4/octave/config.h:985:1: warning: "PACKAGE_NAME" redefined
> conftest.cpp:2:1: warning: this is the location of the previous definition
> /usr/include/octave-3.2.4/octave/config.h:988:1: warning: "PACKAGE_STRING" redefined
> conftest.cpp:5:1: warning: this is the location of the previous definition
> /usr/include/octave-3.2.4/octave/config.h:991:1: warning: "PACKAGE_TARNAME" redefined
> conftest.cpp:3:1: warning: this is the location of the previous definition
> /usr/include/octave-3.2.4/octave/config.h:997:1: warning: "PACKAGE_VERSION" redefined
> conftest.cpp:4:1: warning: this is the location of the previous definition
> /usr/lib/octave-3.2.4/liboctinterp.so: undefined reference to `gzungetc@ZLIB_1.2.0.2'
> collect2: ld returned 1 exit status
>
>
> What does
>
> mkoctfile -p LIBS
> mkoctfile -p LDFLAGS
>
> tell you? Please inform me.
>
> Try feeding these values back to configure with ./configure LDFLAGS=...
> LIBS=...
>
>

The configure script doesn't try to link Sage and Octave together. It doesn't even try linking Python and Octave together.

You will need to add LDFLAGS to the configuration such that the necessary libraries are found for linking Octave. You'll probably need to add the math library to make Python linking work (-lm).

It looks like Octave was linked correctly to when I removed the zlib
library from sage installation.

The other error of the configure file arises when compiling this :

#include <Python.h>
int main ()
{
   Py_Initialize();
   return 0;
}

On my laptop it can be compiled using (the file is named test.c) :

gcc -I/usr/include/python2.6 -L/usr/lib/python -lpython2.6 test.c

By comparison the line in the configure file is :

gcc -I/home/pablo/Source/sage-4.4/local/include/python2.6
-L/home/pablo/Source/sage-4.4/local/lib/python2.6/config -Xlinker
-export-dynamic -lpthread -ldl -lutil -lm -lpython2.6 test.c

Then I checked the content of /lib/python2.6/config (on the server) and
I saw that it doesn't contain any libpython2.6.so file (there is only a
libpython2.6.a) contrary to my laptop. I am not sure what is the
differences of these file.

Can I do something with the .a file ?

Le 11/05/2010 18:56, David Grundberg a écrit :
> The configure script doesn't try to link Sage and Octave together. It
> doesn't even try linking Python and Octave together.
>
> You will need to add LDFLAGS to the configuration such that the
> necessary libraries are found for linking Octave. You'll probably need
> to add the math library to make Python linking work (-lm).
>
>

After spending some time on it, I could compile pytave under sage but I now get a runtime exception (and another bug with python interpreter). Here are the steps I have followed (which I will summarize properly when the whole thing is done) :

* sage -sh # loads sage subshell with its environment variables
* compile/install the boost library
* compile/install octave (a pending bug prevents it from compiling withouth X libraries so xorg-dev has to be installed) # I compiled octave because it needs zlib which is included in sage and results in version conflicts
* go to pytave subdirectory and run :
 - LINK = `"python -c "import distutils.sysconfig; print distutils.sysconfig.get_config_var('LINKFORSHARED')"
- ./configure CFLAGS="$LINK -lm" LDFLAGS="-L/home/pablo/Source/sage-4.4/local/lib/python2.6/config -L/home/pablo/Source/boost_1_43_0/stage/lib/"
- python setup.py build
- python setup.py install

Then I get interesting bugs (some of them may be related to Sage). I wrote a simple test file containing
'''
from pytave import pytave
pytave.eval(0,'a=213')
print pytave.eval(1,'a')
''
then running :
- ./sage test.py # no problem
- ./sage -ipython test.py # no problem

but if I use interactive interpreter,
- ./sage then import pytave
I get a long backtrace which I attach here. I don't know how to interpret this one. Any clue ?

Also (this is not related to sage) when I run :
- ./sage -python then import pytave
- python then import pytave # system wide python on my laptop
I get octave greeting message and end up with octave command line. It works perfectly with IPython.

On 05/17/2010 03:05 PM, albop wrote:

>
> but if I use interactive interpreter,
> - ./sage then import pytave
> I get a long backtrace which I attach here. I don't know how to interpret this one. Any clue ?

The problem is conflicting implementations of Array<int>. Both liboctave
and Singular have their own

template <class T> class Array

with an int instantiation.

> Also (this is not related to sage) when I run :
> - ./sage -python then import pytave
> - python then import pytave # system wide python on my laptop
> I get octave greeting message and end up with octave command line. It works perfectly with IPython.

The GNU Octave greeting message is supposed to be shown on interactive
sessions. This is a deliberate feature. The python interpreter is still
supposed to print its prompt and accept input, though.

You mean octave print the octave:1> prompt and you can type octave
statements? That's a new one. There was a bug *in Octave* overriding the
readline *history* (but readline still working for the python
interpreter) that I know of.

David

The explantion seems convincing. I will try to disable singular but I don't know how necessary it is to the sage system. I'll keep you updated anyway.

Also, I tried again with the Python interpreter, and (stupid me !) I wasnt used to the >>> greeting from Python, I thought it was from octave. So there is no bug here.

Pablo

Marking incomplete; any updates on this?

After some more investigations (cf sage devel list : http://<email address hidden>/msg38963.html) I gave up.
The conflicting library in Sage (singular) cannot be easily modified. Namespacing in Octave is not going to come in a foreseeable future. Apparently the way to get rid of the problem would consist in encapsulating Octave or pytave in a C++ library with a proper namespace, but I have not managed to do it (I'm not a C++ guru though). Yet I would happily test it again if someone manage to find a fix.

Pablo