Sage on openSUSE 12.1

[Simon King]

Hi!

I recently got a laptop, and I have a linux partition on it, namely
openSUSE 12.1.

So far, I have trouble building Sage.

sage-4.8.alpha3 did build, but maxima would not start, because it can
not find mgnuplot

> ./sage -maxima
/home/simon/SAGE/sage-4.8.alpha3/local/bin/maxima: lisp="mgnuplot" not
known. Use --list-avail to see possible options.

No idea where to get that from. gnuplot is installed (and it is not
listed as dependency anyway).

Next, I tried to build sage-4.7.2, but that went even worse, when
building readline:

/bin/sh ../support/shlib-install -O linux-gnu -V unknown -d /home/
simon/SAGE/sage-4.7.2/local/lib64 -b /home/simon/SAGE/sage-4.7.2/local/
bin -i "/usr/bin/install -c -m 644" libreadline.so.6.1
install: you may need to run ldconfig
make[3]: Leaving directory `/home/simon/SAGE/sage-4.7.2/spkg/build/
readline-6.1/src/shlib'
make[2]: Leaving directory `/home/simon/SAGE/sage-4.7.2/spkg/build/
readline-6.1/src'
Error: Readline's build claims to have finished, but files that should
have been built weren't.

Indeed, in the install.log, I read:

rm -f libreadline.a
ar cr libreadline.a readline.o vi_mode.o funmap.o keymaps.o parens.o
search.o rltty.o complete.o bind.o isearch.o display.o signals.o
util.o kill.o undo.o macro.o input.o callback.o terminal.o text.o
nls.o misc.o compat.o xfree.o xmalloc.o history.o histexpand.o
histfile.o histsearch.o shell.o mbutil.o tilde.o
test -n "ranlib" && ranlib libreadline.a

and later

mv /home/simon/SAGE/sage-4.8.alpha3/local/lib/libreadline.a /home/
simon/SAGE/sage-4.8.alpha3/local/lib/libreadline.old
mv: Aufruf von stat für „/home/simon/SAGE/sage-4.8.alpha3/local/lib/
libreadline.a“ nicht möglich: Datei oder Verzeichnis nicht gefunden
make[2]: [install-static] Fehler 1 (ignoriert)
/usr/bin/install -c -m 644 libreadline.a /home/simon/SAGE/
sage-4.8.alpha3/local/lib/libreadline.a
test -n "ranlib" && ranlib /home/simon/SAGE/sage-4.8.alpha3/local/lib/
libreadline.a
mv /home/simon/SAGE/sage-4.8.alpha3/local/lib/libhistory.a /home/simon/
SAGE/sage-4.8.alpha3/local/lib/libhistory.old
mv: Aufruf von stat für „/home/simon/SAGE/sage-4.8.alpha3/local/lib/
libhistory.a“ nicht möglich: Datei oder Verzeichnis nicht gefunden

In other words, apparently it has created libreadline.a (and also
libhistory.a), but when it tries to move it to a different location
then the files are gone.

Any idea how to debug this? Are these two known issues?

Cheers,
Simon

[Volker Braun]

The general problem with libreadline is that a lot of programs outside of Sage use it. So many distributions break if we just LD_LIBRARY_PATH a different version of libreadline, suddenly your shell doesn't work any more etc. There are then hacks for Suse and Arch linux in the readline spkg to perhaps copy the system readline. Then the shell does work but some programs in Sage perhaps no longer. It seems like some of the assumption about the locations of files is the readline spkg-install are violated on your version of Suse.

Really, this is why LD_LIBRARY_PATH is considered a bad solution for forcing libraries that doesn't scale to big projects. This is not a new conclusion, many others have been burned there before. The known solution to this is to use rpaths. This is what the compilerwrapper http://trac.sagemath.org/sage_trac/ticket/10572 is about.

[Simon King]

Hi Volker,

On 8 Dez., 14:06, Volker Braun <vbraun.n...@gmail.com> wrote:
> Really, this is why LD_LIBRARY_PATH is considered a bad solution for
> forcing libraries that doesn't scale to big projects. This is not a new
> conclusion, many others have been burned there before. The known solution
> to this is to use rpaths. This is what the
> compilerwrapperhttp://trac.sagemath.org/sage_trac/ticket/10572is about.

Does that mean you suggest that I do "./sage -i ..." with the spkg of
that ticket, apply the given patch, and then do "make" again?

Cheers,
Simon

[Volker Braun]

No, its not a plug-in solution. After we adapt the compilerwrapper we need to remove the workarounds from the readline spkg, for example.

[Simon King]

Hi Volker,

On 8 Dez., 15:02, Volker Braun <vbraun.n...@gmail.com> wrote:
> No, its not a plug-in solution. After we adapt the compilerwrapper we need
> to remove the workarounds from the readline spkg, for example.

That sounds like my choice of a Linux distribution was a severe
mistake. I was much looking forward to finally have Sage on my Laptop,
but now I am again back to the use-Windows-to-connect-with-the-
computer-in-my-office-and-work-on-Sage-there workaround.

Cheers,
Simon

[Volker Braun]

Well for once its not Suse's fault but our own for abusing LD_LIBRARY_PATH. But having said that, if you want to install linux specifically for the purpose of running Sage then I would recommend Ubuntu or Fedora (depending on whether your are less or more technically inclined). They just get more exposure, thats all.

[Simon King]

Hi Volker,

On 8 Dez., 15:31, Volker Braun <vbraun.n...@gmail.com> wrote:
> Well for once its not Suse's fault but our own for abusing LD_LIBRARY_PATH.
> But having said that, if you want to install linux specifically for the
> purpose of running Sage then I would recommend Ubuntu or Fedora

I was explicitly deciding against Ubuntu, because I made the
experience on the computers here in the department that the pseudoTTY
had a very high latency, and thus all pexpect interfaces were running
extremely slow. I am too lazy to look up the sage-devel thread on that
topic. The problem comes with every Linux distribution based Debian,
and the solution is to patch the Linux kernel, but I didn't feel
confident of doing this myself.

And then I remembered good experiences with running Sage on some
Laptop a few years ago, which was on SUSE. So, I thought openSUSE was
a good choice. Too bad.

Best regards,
Simon

[Simon King]

Hi Volker,

On 8 Dez., 15:31, Volker Braun <vbraun.n...@gmail.com> wrote:
> Well for once its not Suse's fault but our own for abusing LD_LIBRARY_PATH.

That may be to blame for the error that I find for sage-4.8.alpha3
(namely maxima not starting because it can't find mgnuplot).

But can the problem with sage-4.7.2 really be caused by
LD_LIBRARY_PATH as well? I mean, according to the install.log (that I
may be able to post tomorrow), libreadline.a has been created, but
nevertheless it can't be found when trying to rename it into
libreadline.old.

However, I do remember that I needed to define LD_LIBRARY_PATH a few
years ago, when I was working on openSUSE.

Best regards,
Simon

[Volker Braun]

I think I'll be able to say more if you show me the install.log ;-)

[Dima Pasechnik]

well, can't we just use the system's readline instead?

I cannot imagine a recent Linux distribution for which such readline doesn't work with Sage.

[Georg S. Weber]

On 8 Dez., 23:54, Volker Braun <vbraun.n...@gmail.com> wrote:
> I think I'll be able to say more if you show me the install.log ;-)

I agree. Possibly, some lightly tweaked new readline spkg solves this
problem. But to have chance, a bit more information seems to be
needed.

Cheers,
Georg

[Georg S. Weber]

Hi,

after reading the discussion at http://trac.sagemath.org/sage_trac/ticket/10572
it occured to me that as a rule, rules comes with exceptions.

More precisely, renaming the readline library that is bundled with
sage as "sage-readline" and adapting the R spkg to look for "sage-
readline" (I don't think there is any other spkg needing the readline
library that comes with Sage, or is there?), might have saved us a
good part of the failure reports in the past ...

Of course I agree that renaming all libraries (png, whatnot) that come
with Sage is not a good idea.

Cheers,
Georg

[Thomas Hupfer]

Hi,

I don't think that there still is a problem with readline on Suse.

after a lot of struggling, I managed to build sage 4.7.2 on openSuSE
12.1 (64bit) on my desktop computer and my laptop a few weeks ago.
Also see the thread
https://groups.google.com/group/sage-devel/browse_thread/thread/02e4352f91cb157b#
in this forum.
Since then everything seems to work fine, so Suse is fine for sage.

The problem was not specific to libreadline but rather that several
sage-packages put files in $SAGE_LOCAL/local/lib64 instead of
$SAGE_LOCAL/local/lib where they are expected by the sage build
system. libreadline just happens to be the first package where this
issue appears.

My workaround was to make one of the aforementioned directories a
symlink to the other, after unpacking the sage sources but before
building.

I hope that someone with deeper understanding of the build system
would look at this lib/lib64 issue to fix it.
Maybe this already happened in sage 4.8 alpha 3.

Regards,
Thomas

[Simon King]

Dear Thomas.

On 9 Dez., 09:29, Thomas Hupfer <thomas.a.hup...@googlemail.com>
wrote:

> My workaround was to make one of the aforementioned directories a
> symlink to the other, after unpacking the sage sources but before
> building.

Thank you for your hint!

I forgot to bring my laptop to university, so, I can't test it now,
and I am afraid (@Georg) I also can't post the install.log...

> I hope that someone with deeper understanding of the build system
> would look at this lib/lib64 issue to fix it.
> Maybe this already happened in sage 4.8 alpha 3.

That would explain why sage-4.8.alpha3 did build out of the box.
Still, maxima can't be started in that version.

Cheers,
Simon

[Volker Braun]

On Friday, December 9, 2011 8:28:26 AM UTC, Georg S. Weber wrote:

I don't think there is any other spkg needing the readline
library that comes with Sage, or is there?

Isn't pretty much every program with a stand-alone command line going to use readline? A quick grep in $SAGE_LOCAL/bin finds Singular, gp, and sqlite3. Others (like R I guess) dload it from libraries so its not in the executable. 

 

[Volker Braun]

On Friday, December 9, 2011 5:43:41 AM UTC, Dima Pasechnik wrote:

well, can't we just use the system's readline instead?

I think the reason is because OSX doesn't ship with readline since its GPL. Apple hacked in a readline replacement by ripping off some BSD code but its not 100% compatible. 

[Volker Braun]

Good observation. I made a trac ticket with the two possible fixes at http://trac.sagemath.org/sage_trac/ticket/12131

Can you look into your lib64 directory and tell us which spkgs got installed there?

[Thomas Hupfer]

On 9 Dez., 12:05, Volker Braun <vbraun.n...@gmail.com> wrote:
> Good observation. I made a trac ticket with the two possible fixes athttp://trac.sagemath.org/sage_trac/ticket/12131
>

Thank you.

> Can you look into your lib64 directory and tell us which spkgs got
> installed there?

I'm sorry, I can't. The unsuccessful builds are gone and in the
successful ones lib and lib64 are identical (symlinks).
I don't know if there is a useful log.
I'd prefer to not go again through the build without the symlink as it
stops after each error and I tricked it to continue for a while with
symlinks for individual files.

In my handwritten notes I find besides readline that libgmp.so.3,
libmftr.so, and libcddgmp.a were in lib64, but this list is probably
incomplete.
These errors showed up in building ecl, mpfi, gfan and maxima.

[Thomas Hupfer]

> Can you look into your lib64 directory and tell us which spkgs got
> installed there?

I had a look at install.log:

grep "local/lib64/" install.log | grep "^/usr/bin/install" | cut -d
4 -f 2 | cut -d / -f 2 | cut -d . -f 1 | sort | uniq

gives:

ecl-11
libcord
libfplll
libfreetype
libgc
libgcrypt
libgd
libgivaro
libgmp
libgmpxx
libgnutls
libgnutls-extra
libgnutls-openssl
libgpg-error
libiml
liblinbox
liblinboxsage
libmpfi
libmpir
libmpirxx
libopencdk
libsqlite3
python2

I hope this helps.

[Julien Puydt]

Le 09/12/2011 09:28, Georg S. Weber a �crit :

What about making sage use the system readline by default instead?

Snark on #sagemath

[Georg S. Weber]

On 9 Dez., 15:24, Julien Puydt <julien.pu...@laposte.net> wrote:
> Le 09/12/2011 09:28, Georg S. Weber a crit :

>

> What about making sage use the system readline by default instead?
>
> Snark on #sagemath

Hi Julien,

unfortunately, there are some OSes (I think Solaris was one of
them?!), where the default readline library available is judged as
"not good/new enough" by certain components of Sage. I'm pretty
certain that R is one of these --- maybe the only one?
If so, a mixed approach might work. More precisely, we continue to
have a (new enough) readline spkg, rename the readline lib built by it
to, say, sage-readline, but link only as few as possible other
components of Sage to it. Since the major part of the components will
work fine with the system readline on any of the supported OSes.

Thoughts?

Cheers,
Georg

[William Stein]

You also need the readline devel headers, which potentially increases the dependencies to build Sage. 

>
>
> Cheers,
> Georg
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

[Dima Pasechnik]

well, this doesn't mean that Sage cannot get a flag to switch to the system-wide readline, which would have allowed an easy workaround in the case discussed here.

 

[Simon King]

On 9 Dez., 09:13, "Georg S. Weber" <georgswe...@googlemail.com> wrote:
> On 8 Dez., 23:54, Volker Braun <vbraun.n...@gmail.com> wrote:
>
> > I think I'll be able to say more if you show me the install.log ;-)
>
> I agree.

The install log for my failing attempt on sage-4.7.2 is here:
http://sage.math.washington.edu/home/SimonKing/SAGE/install_logs/4.7.2/install.log

I did export LD_LIBRARY_PATH, namely
simon@linux-sqwp:~/SAGE/sage-4.7.2> echo $LD_LIBRARY_PATH
/usr/local/lib64/:/usr/local/lib/

So, that wasn't enough to solve the problem.

I am now trying to repeat building sage-4.8.alpha3, with
LD_LIBRARY_PATH (which I didn't use in my first attempt; recall that
it seemed to succeed, but resulted in a dysfunctional maxima.

Best regards,
Simon

[Simon King]

Hi!

To my surprise, the second attempt to build sage-4.8.alpha3 now fails
in the same way as sage-4.7.2. Strange. It is a pity that I didn't
save the old install log!

The new one is at http://sage.math.washington.edu/home/SimonKing/SAGE/install_logs/4.8.alpha3/install.log

Cheers,
Simon

[Volker Braun]

Just as a proof of concept, here is a readline spkg that does ./configure --libdir="$SAGE_LOCAL/lib" to fix the lib64 built-in:

http://www.stp.dias.ie/~vbraun/Sage/spkg/readline-6.2.p2.spkg

This will get you across the first hurdle but I highly doubt that the remaining spkgs will build...

[Simon King]

On 9 Dez., 20:41, Simon King <simon.k...@uni-jena.de> wrote:
> To my surprise, the second attempt to build sage-4.8.alpha3 now fails
> in the same way as sage-4.7.2. Strange. It is a pity that I didn't
> save the old install log!

If I understand correctly, libreadline.a is attempted to be created,
by

ar cr libreadline.a readline.o vi_mode.o funmap.o keymaps.o parens.o
search.o rltty.o complete.o bind.o isearch.o display.o signals.o
util.o kill.o undo.o macro.o input.o callback.o terminal.o text.o
nls.o misc.o compat.o xfree.o xmalloc.o history.o histexpand.o
histfile.o histsearch.o shell.o mbutil.o tilde.o
test -n "ranlib" && ranlib libreadline.a

Why isn't $AR used, anyway? I was told one should use that kind of
environment variables.

I have
simon@linux-sqwp:~/SAGE/sage-4.8.alpha3> ar --version
GNU ar (GNU Binutils; openSUSE 12.1) 2.21.1
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.

I am not 100% sure, but it could be that I was installing binutils
only after my first attempt to build sage-4.8.alpha3. Could it be that
that ar is broken? How could I find out?

Cheers,
Simon

[Simon King]

Hi Volker,

It works! I am indeed past readline.

Let's keep the fingers crossed...

Thank you,
Simon

[Simon King]

Hi Volker,

On 9 Dez., 20:55, Volker Braun <vbraun.n...@gmail.com> wrote:

Things only broke in the python spkg.

The new install.log is at http://sage.math.washington.edu/home/SimonKing/SAGE/install_logs/4.8.alpha3/install.log.2
(note the new name, install.log.2)

Cheers,
Simon

[Simon King]

Hi!

On 9 Dez., 21:19, Simon King <simon.k...@uni-jena.de> wrote:
> Things only broke in the python spkg.

And the problem is that libpython2.6.so.1.0 can't be found. But there
*is* libpython2.6.so.1.0, namely at $SAGE_ROOT/local/lib64/ !!

So, why is Sage not looking there?

Cheers,
Simon

[Volker Braun]

If you symlink $SAGE_LOCAL/lib64 -> $SAGE_LOCAL/lib then it should work.

Python's configure script would again need --libdir="$SAGE_LOCAL/lib" added. We should probably fix all ocurences, even if it is painful. But for now why not do the symlink kludge.

[Simon King]

Hi Volker,

On 9 Dez., 22:12, Volker Braun <vbraun.n...@gmail.com> wrote:
> Python's configure script would again need --libdir="$SAGE_LOCAL/lib"
> added.

I have done that, and now Sage came past Python and past Fortran. Now
I am looking forward for Atlas to build.

> We should probably fix all ocurences, even if it is painful. But for
> now why not do the symlink kludge.

Well. My plan is to make my new laptop ready for work. So, I will keep
adding --libdir="$SAGE_LOCAL/lib", and if this succeeds then I will
post create spkg updates that I will post on the ticket #12131.

*If* it succeeds then I must not forget to erase my setting of
"LD_LIBRARY_PATH", to see if it would still work.

Cheers,
Simon

[Simon King]

Hi!

Things went quite far, actually the next error has only been in the
ecl-11.1.2.cvs20111120.p0 spkg

The new install log is at http://sage.math.washington.edu/home/SimonKing/SAGE/install_logs/4.8.alpha3/install.log.3

This time, libgmp.so.8 can't be found (although it is in SAGE_LOCAL/
lib64. I assume this means that I have to modify gmp, not ecl?

Cheers,
Simon

[Volker Braun]

Yes, this would be gmp/mpir's fault.

[Simon King]

Hi all!

I made some progress. I modified the following spkgs to use --
libdir="$SAGE_LOCAL/lib":

* readline (I used Volker's version)
* python
* mpir
* boehm_gc
* givaro
* mpfr
* mpfi
* r

Now, building the Sage library code fails, more precisely: M4RI.

I suppose that I'll now have to modify M4RI and M4RIE.

One question: If I remember correctly, openSUSE is one of the most
common Linux distributions, at least in Germany. Since we are
approaching a new major version of Sage, I'd like to make #12131 a
blocker for sage-5.0. Do you think that's OK?

Cheers,
Simon

[Volker Braun]

On Saturday, December 10, 2011 9:17:53 AM UTC, Simon King wrote:

One question: If I remember correctly, openSUSE is one of the most
common Linux distributions, at least in Germany.

Probably only in Germany ;-)

I would be in favor of making it a blocker. Its really only a one-line change and if you can make it work then we should bump all spkgs as soon as possible. Jeroen, are you going to do another alpha to try that out?

[Simon King]

Hi Volker,

On 10 Dez., 11:10, Volker Braun <vbraun.n...@gmail.com> wrote:
> I would be in favor of making it a blocker. Its really only a one-line change

A one-line change that needs to be done in at least 12 packages,
though.

[Jeroen Demeyer]

On 2011-12-10 11:10, Volker Braun wrote:
> I would be in favor of making it a blocker. Its really only a one-line
> change and if you can make it work then we should bump all spkgs as soon
> as possible. Jeroen, are you going to do another alpha to try that out?

I could, yes. I have some other things I would like to merge in
sage-4.8, like #12016 for example.

And OS X Lion was supposed to be fixed in sage-4.8, but those tickets
seem to have fallen asleep.

What is the ticket number?
Also, please explain the issue on the ticket, because I haven't been
following the whole discussion here.

[Volker Braun]

On Saturday, December 10, 2011 10:38:34 AM UTC, Jeroen Demeyer wrote:

What is the ticket number?
Also, please explain the issue on the ticket, because I haven't been
following the whole discussion here.

 http://trac.sagemath.org/sage_trac/ticket/12131

[William Stein]

On Sat, Dec 10, 2011 at 2:38 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2011-12-10 11:10, Volker Braun wrote:
>> I would be in favor of making it a blocker. Its really only a one-line
>> change and if you can make it work then we should bump all spkgs as soon
>> as possible. Jeroen, are you going to do another alpha to try that out?
> I could, yes.  I have some other things I would like to merge in
> sage-4.8, like #12016 for example.
>
> And OS X Lion was supposed to be fixed in sage-4.8, but those tickets
> seem to have fallen asleep.

The Fall academic quarter at UW ends in a few days. The main people
working on those tickets are me and John Palmieri, who are both
teaching at UW, so I predict an awakening soon.

William

>
> What is the ticket number?
> Also, please explain the issue on the ticket, because I haven't been
> following the whole discussion here.
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Simon King]

Hi!

Eventually, it was a one-line change in 29 packages. See #12131, which
is now needing review. I made it a blocker for sage-5.0, but if people
think that openSUSE 12.1 could already be supported by sage-4.8, I
wouldn't object...

Cheers,
Simon

[Jeroen Demeyer]

On 2011-12-12 00:15, Simon King wrote:
> Eventually, it was a one-line change in 29 packages. See #12131, which
> is now needing review. I made it a blocker for sage-5.0, but if people
> think that openSUSE 12.1 could already be supported by sage-4.8, I
> wouldn't object...

If it gets reviewed soon enough, then I agree.