Re: FreeBSD and Sage
Karl-Dieter Crisman
>>>>>>>
>>>>>>> and these tickets from your message below:
>>>>>>>
>>>>>>> Numpy - http://trac.sagemath.org/sage_trac/ticket/7831
>>>>>>> Singular - http://trac.sagemath.org/sage_trac/ticket/7832
>>>>>>> R - http://trac.sagemath.org/sage_trac/ticket/8274
>>>>>>> Cephes - http://trac.sagemath.org/sage_trac/ticket/9543
>>>>>>> flintqs - http://trac.sagemath.org/sage_trac/ticket/9544
>>>>>>> ATLAS - http://trac.sagemath.org/sage_trac/ticket/9600
>>>>>>> cvxopt - http://trac.sagemath.org/sage_trac/ticket/9601
>>>>>>> GAP - http://trac.sagemath.org/sage_trac/ticket/9602
>>>>>>> matplotlib - http://trac.sagemath.org/sage_trac/ticket/5873
>>>>>>>
>>>>>>> Anything else he should be aware of?
>>>>
>>>>
>>>>
>>>> Dear Michael and Stephen,
>>>>
>>>> Just a reminder that we still welcome any FreeBSD help :) And
>>>> pointing you to http://wiki.sagemath.org/freebsd as yet another page
>>>> that apparently has a little information about this.
>>>>
>>> It will probably be the summer before I can get into this seriously.
>>>
>>> In the meantime, I have joined the sage-dev list.
>>>
>> That's a great first step, I hope you see something of interest on
>> occasion.
>
>
> OK, I started working on building sage. So far I can get all the spkg's to
> build except:
>
> gap-4.4.12.p6
> pycrypto-2.1.0
> singular-3-1-3-3.p3
> maxima-5.23.2.p3
> sage-4.8
That's great. Some of these aren't yet at the list of FreeBSD
tickets, http://trac.sagemath.org/sage_trac/query?status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&component=FreeBSD&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component
> The build problem with pycrypto-2.1.0 and singular-3-1-3-3.p3 are easy to
> fix. The hard thing is to know how to apply a patch before one does the
> "make".
Ah, yes, this is a little hard. See
http://www.sagemath.org/doc/developer/patching_spkgs.html, though that
is more detail than you need. Really, you just need to untar the
.spkg file, make your change, then tar it back up. I think that the
specific commands are at
http://www.sagemath.org/doc/developer/producing_spkgs.html#creating-a-new-spkg.
> The build problem with sage-4.8 is that it claims that I don't have a
> working sem_open. But I clearly do. Where does it do this detection? Is it
> somewhere in the build of python?
Probably something in Python didn't get built that should. Seeing
more of the details would help.
> The problems with gap and maxima look like I need to investigate further.
GAP at least is known, apparently - see
http://trac.sagemath.org/sage_trac/ticket/9602
> Also the instructions at
> http://www.sagemath.org/doc/installation/source.html suggest that sage uses
> libtiff somewhere. But is this still the case? Source code of tiff doesn't
> seem to be in the list of stuff in spkg.
You need this to pass/use certain stuff in plotting. See
http://trac.sagemath.org/sage_trac/ticket/7345.
For now, our goal would just be to successfully *build* Sage.
> I had to use the FreeBSD port of atlas.
Okay. We can eventually add having atlas on the machine to the
prereqs; on Mac OSX we use the system ATLAS.
> I only just started today. I really have very little idea of how to submit
> patches and such like. I am teaching a new class this semester, and I
That's ok, we can guide you through this.
> thought it would eat up all my time. But it looks like I have a short
> respite. Nevertheless, I haven't been following sage-devel, and I haven't
> learned the ropes about how to submit patches or ask for changes.
>
> In case you are interested, I am attaching the early workings of the FreeBSD
> port I plan to submit when I have it all worked out.
I think the best strategy for immediately is for you to get a Trac
account so that you can put your experiences with each (failing)
package there for others to be able to help. See
http://trac.sagemath.org/sage_trac/ and follow the instructions at the
top. Then you can either post your failure messages to appropriate
tickets, or open a new one (for instance for the pycrypto).
Thanks! Please let us know if you have any other questions. I
encourage you to continue this conversation at sage-devel, where I am
cross-posting this response.
- kcrisman
Stephen Montgomery-Smith
main problem that seems to be holding me up is when I try to build the
sage4.8 subpackage. I get an error that says that sem_opn is not
functioning. However I am using a version of FreeBSD that has
semaphores installed by default.
I am guessing that the problem might be in the build of python, which
might incorrectly autodetect that sem_opn is not functioning.
Can anyone give me guidance on how to approach this problem?
Thanks, Stephen
Stephen Montgomery-Smith
Hey, I figured it out. I hope to get a working sage on FreeBSD soon.
Stephen Montgomery-Smith
contains a "port" to build sage on FreeBSD. (FreeBSD users will know
what I mean by a "port.")
It does seem to work, but it segfaults on exit:
%./sage
----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: 1+1
2
sage: exit
Exiting Sage (CPU time 0m0.03s, Wall time 0m6.24s).
local/bin/sage-sage: line 303: 22511 Segmentation fault: 11 (core
dumped) sage-ipython "$@" -i
Any ideas on how to proceed?
Stephen Montgomery-Smith
I did a "sage -gdb" and it suggests that the problem might be to do with
~Commentator in commentator.C. This is part of the linbox subpackage.
I did a google and found this:
http://trac.sagemath.org/sage_trac/ticket/11718
Does construction and/or deconstruction of Commentator tend to cause
problems?
Paulo César Pereira de Andrade
I do not remember all details about this, but hopefully this can help
http://svn.mandriva.com/viewvc/packages/cooker/linalg-linbox/current/SOURCES/linbox-1.1.6-build.patch?view=markup
Paulo
Stephen Montgomery-Smith
I tried this, and it didn't seem to work in my situation.
Stephen Montgomery-Smith
I fixed the problem as follows:
sed -i .bak -e 's/Commentator/Commensator/g' \
"$SAGE_ROOT"/local/lib/liblinboxsage.so.0
That way sage didn't get confused between the Commentator that appears
in liblinbox and liblinboxsage.
Now I am getting a different segmentation fault, for which unfortunately
gdb provides no clues.
François Bissey
Can you still post what output/debugging info you have?
Francois
Stephen Montgomery-Smith
I am in the process of compiling with the "-g" option set. I'll send
you the output when this is done.
Stephen Montgomery-Smith
The "-g" option didn't seem to help one bit. This is what I got.
Not all of the subpackages respect CFLAGS or CXXFLAGS. But I don't know
if that is the reason the symbols are not showing up.
Any advice?
%./sage -gdb
----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
/usr/home/stephen/sage/work/sage-4.8/local/bin/sage-ipython
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
[New LWP 100403]
[New Thread 8012041c0 (LWP 100403/initial thread)]
Python 2.6.4 (r264:75706, Jan 22 2012, 22:20:43)
[GCC 4.6.3 20120113 (prerelease)] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
sage:
Exiting Sage (CPU time 0m0.02s, Wall time 0m2.62s).
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8012041c0 (LWP 100403/initial thread)]
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x0000000800f1b086 in __cxa_finalize () from /lib/libc.so.7
#2 0x0000000800ec5787 in exit () from /lib/libc.so.7
#3 0x000000080084a91f in Py_Exit (sts=Variable "sts" is not available.
) at Python/pythonrun.c:1618
#4 0x000000080084aa0f in handle_system_exit () at Python/pythonrun.c:1618
#5 0x000000080084ac95 in PyErr_PrintEx (set_sys_last_vars=1)
at Python/pythonrun.c:1618
#6 0x0000000000000000 in ?? ()
#7 0x00000008006037ed in ?? () from /libexec/ld-elf.so.1
#8 0x00007fffffffdde0 in ?? ()
#9 0x0000000000600d29 in ?? ()
#10 0x000000085d2018c8 in ?? ()
#11 0x0000000000600d28 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0x000000080ea00248 in ?? ()
#14 0x0000000000600d28 in ?? ()
#15 0x00000000ffffffff in ?? ()
#16 0x0000000000000000 in ?? ()
#17 0x0000000000000206 in ?? ()
#18 0x00000008012171fe in ?? ()
#19 0x00000008012b29e0 in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x000000080084b10e in PyRun_SimpleFileExFlags (fp=Variable "fp" is
not available.
)
---Type <return> to continue, or q <return> to quit---
at Python/pythonrun.c:1618
#22 0x00007fffffffe010 in ?? ()
#23 0x00000008006037ed in ?? () from /libexec/ld-elf.so.1
#24 0x0000000000000246 in ?? ()
#25 0xffffff00bac20000 in ?? ()
#26 0x0000000801086c20 in __stack_chk_guard () from /lib/libc.so.7
#27 0x0000000000000003 in ?? ()
#28 0x0000000801086c20 in __stack_chk_guard () from /lib/libc.so.7
#29 0x00000008012171fe in ?? ()
#30 0x00007fffffffe010 in ?? ()
#31 0x00007fffffffe0e8 in ?? ()
#32 0x00000008012171fe in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000001 in ?? ()
#35 0x0000000801086c20 in __stack_chk_guard () from /lib/libc.so.7
#36 0x0000000800afd140 in Py_InteractiveFlag ()
from /usr/home/stephen/sage/work/sage-4.8/local/lib//libpython2.6.so.1
#37 0x000000080085802f in Py_Main (argc=Variable "argc" is not available.
) at Modules/main.c:109
#38 0x000000080088a753 in hexdigits ()
from /usr/home/stephen/sage/work/sage-4.8/local/lib//libpython2.6.so.1
#39 0x0000000000000000 in ?? ()
#40 0x0000000000000000 in ?? ()
#41 0x0000000000632000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#42 0x00000008010566e0 in __stderrp () from /lib/libc.so.7
#43 0x0101000000000001 in ?? ()
#44 0x0000000000000001 in ?? ()
#45 0x00000008006093f9 in dlopen () from /libexec/ld-elf.so.1
#46 0x00000008006066f4 in dladdr () from /libexec/ld-elf.so.1
#47 0x00000008006037ed in ?? () from /libexec/ld-elf.so.1
#48 0x0000000000000246 in ?? ()
#49 0xffffff00bac20000 in ?? ()
#50 0x0000000000000000 in ?? ()
#51 0x0000000000000340 in ?? ()
#52 0x0000000000000000 in ?? ()
#53 0x00007fffffffe0e8 in ?? ()
#54 0x000000000000037f in ?? ()
#55 0x0000000000000002 in ?? ()
#56 0x00007fffffffe0c0 in ?? ()
#57 0x00007fffffffe100 in ?? ()
#58 0x00007fffffffe0e8 in ?? ()
#59 0x0000000000000000 in ?? ()
#60 0x0000000000000000 in ?? ()
#61 0x0000000000400618 in main (argc=Variable "argc" is not available.
) at ./Modules/python.c:23
(gdb)
François Bissey
> On 01/22/2012 04:28 PM, Stephen Montgomery-Smith wrote:
> >> On Sun, 22 Jan 2012 15:54:19 Stephen Montgomery-Smith wrote:
> >>> On 01/21/2012 08:23 PM, Stephen Montgomery-Smith wrote:
> >>>> On 01/21/2012 08:05 PM, Stephen Montgomery-Smith wrote:
> >>>>> I am able to build sage on FreeBSD. I have attached a tar file
> >>>>> which
> >>>>> contains a "port" to build sage on FreeBSD. (FreeBSD users will
> >>>>> know
> >>>>> what I mean by a "port.")
> >>>>>
> >>>>> It does seem to work, but it segfaults on exit:
> >>>>>
> >>>>> %./sage
> >>>>> ----------------------------------------------------------------
> >>>>> ------>>>>>
> >>>>> | Sage Version 4.8, Release Date: 2012-01-20 |
> >>>>> | Type notebook() for the GUI, and license() for information.
> >>>>> | |
> >>>>>
> >>>>> ----------------------------------------------------------------
export SAGE_DEBUG=yes
then build.
That little bit makes me suspect an issue similar to:
https://github.com/cschwan/sage-on-gentoo/issues/40
also found on solaris at some point:
http://trac.sagemath.org/sage_trac/ticket/11116
Francois
Stephen Montgomery-Smith
FreeBSD has a working python version 2.7. How do I tell the sage build
to use the FreeBSD python rather than building its own?
François Bissey
sage-on-gentoo that does just that).
Seriously using system python with the stock sage tarball is just asking
for a lot of pain (including serious patching).
I don't think your problem is with python strictly speaking, if it turns out
to be pynac, that's quite different, although discussion is that something
in the sage code can be done to mitigate the issue.
Francois
Paulo César Pereira de Andrade
> On Sun, 22 Jan 2012 17:31:34 Stephen Montgomery-Smith wrote:
>> One thing I want to rule out is that the problem is created by python.
>> FreeBSD has a working python version 2.7. How do I tell the sage build
>> to use the FreeBSD python rather than building its own?
> That kind of scenario is very much unsupported (He says while producing
> sage-on-gentoo that does just that).
> Seriously using system python with the stock sage tarball is just asking
> for a lot of pain (including serious patching).
The major problem is "bootstraping", and possibly "political" issues if you
need patches in other packages you do not maintain. Once you get it
working, usually updating to a newer sagemath is reasonably simple,
just don't let it rot for too long.
François know I did not look in my sage package for almost too months :-)
While I had some known doctest failures for very long due to using a
different version of some component, e.g. python, for several times I
found bugs that just did not trigger in sage due to it not using packages
outside its install tree.
> I don't think your problem is with python strictly speaking, if it turns out
> to be pynac, that's quite different, although discussion is that something
> in the sage code can be done to mitigate the issue.
Since the problem appears to be related to linbox, besides the patch
I suggested, maybe this can help:
$ ldd /usr/lib64/liblinboxsage.so.0.0.0
linux-vdso.so.1 => (0x00007fff24f62000)
libntl.so.5 => /usr/lib64/../lib64/libntl.so.5 (0x00007f1670bd9000)
liblinbox.so.0 => /usr/lib64/../lib64/liblinbox.so.0
(0x00007f16709c7000)
libcblas.so.3 => /usr/lib64/atlas-sse3/libcblas.so.3
(0x00007f167076e000)
libgmp.so.10 => /usr/lib64/../lib64/libgmp.so.10 (0x00007f1670500000)
libgivaro.so.0 => /usr/lib64/../lib64/libgivaro.so.0
(0x00007f16702b2000)
libstdc++.so.6 => /usr/lib64/../lib64/libstdc++.so.6
(0x00007f166ffb4000)
libm.so.6 => /lib64/libm.so.6 (0x00007f166fd30000)
libc.so.6 => /lib64/libc.so.6 (0x00007f166f980000)
libgcc_s.so.1 => /usr/lib64/../lib64/libgcc_s.so.1 (0x00007f166f76b000)
libgf2x.so.1 => /usr/lib64/libgf2x.so.1 (0x00007f166f55d000)
libatlas.so.3 => /usr/lib64/atlas-sse3/libatlas.so.3
(0x00007f166ef44000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f166ed28000)
/lib64/ld-linux-x86-64.so.2 (0x00007f167136c000)
$ ldd /usr/lib64/liblinbox.so.0.0.0
linux-vdso.so.1 => (0x00007fff6bbf0000)
libstdc++.so.6 => /usr/lib64/../lib64/libstdc++.so.6
(0x00007fbf6f86b000)
libm.so.6 => /lib64/libm.so.6 (0x00007fbf6f5ab000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbf6f1fc000)
libgcc_s.so.1 => /usr/lib64/../lib64/libgcc_s.so.1 (0x00007fbf6efe7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbf6fd7b000)
> Francois
Paulo
Stephen Montgomery-Smith
> Since the problem appears to be related to linbox ...
It was related to linbox. My "fix" using sed wasn't working.
What I did was to rebuild linbox. I removed any reference to
-DDISABLE_COMMENTATOR (which I did by hacking commentator.h so that
-DDISABLE_COMMENTATOR had no effect). Then I found I had to remove the
patch to commentator.C that is in patches, so that "Commentator
commentator" is no longer commented out.
Then it worked. sage doesn't crash on exit!!!
I think there is a real problem with linbox and linboxsage both
containing different versions of the same function (namely
~Commentator). I have had prior experience with this, and this sort of
thing seems to bite FreeBSD when other OS's don't get bit at all.
Julien Puydt
> Seriously using system python with the stock sage tarball is just asking
> for a lot of pain (including serious patching).
What kind of pain?
Were does the serious patching apply? In python itself or in dependent
packages?
Snark on #sagemath
Stephen Montgomery-Smith
So it built successfully. I ran "sage -testall" and it did fail a few
of them ("ccosh" not found seemed like a common error).
Is this normal, or should I post test.log and have it analyzed?
Also, I made a few minor corrections to the port, and I will post that
later today.
Stephen Montgomery-Smith
> On 01/22/2012 11:40 PM, Stephen Montgomery-Smith wrote:
>> I have tested this port at least up until a working sage is created. I
>> am going to do a complete build tonight.
>>
>> In the meantime, others can try this out if they like.
>>
> later today.
And here it is.
Dima Pasechnik
Jeroen Demeyer
> "ccosh" not found seemed like a common error.
This might be solvable by installing cephes on FreeBSD. This is
included in Sage but only installed on Cygwin.
François Bissey
> Le 23/01/2012 02:12, François Bissey a écrit :
> > Seriously using system python with the stock sage tarball is just asking
> > for a lot of pain (including serious patching).
>
> What kind of pain?
>
> Were does the serious patching apply? In python itself or in dependent
> packages?
>
> Snark on #sagemath
juggling with PYTHONPATH or put things in a standard system location.
Sage itself need a little bit of care in setup.py so you can find and install
everything. Of course the current python shipped with sage also has a small
but annoying patch that has only been merged recently and will be in
python-2.7.3, some small functionality won't work without it.
Francois
Julien Puydt
> On Mon, 23 Jan 2012 07:24:14 Julien Puydt wrote:
>> Were does the serious patching apply? In python itself or in dependent
>> packages?
> If you want to use system python you have to start doing some serious
> juggling with PYTHONPATH or put things in a standard system location.
> Sage itself need a little bit of care in setup.py so you can find and install
> everything. Of course the current python shipped with sage also has a small
> but annoying patch that has only been merged recently and will be in
> python-2.7.3, some small functionality won't work without it.
Hmmm... my systems seem to have a python 2.7.2+ installed, so I should
probably wait before I experiment about it ;-)
Thanks,
Snark on #sagemath
Stephen Montgomery-Smith
On my system, complex cosh is the cosh function, overloaded to accept
complex arguments. I don't have complex.h for C++ - rather I would use
#include <cmath>
#include <complex>
I had a similar problem with sage-main/sage/symbolic/pynac_cc.h, which
was looking for functions like logl. I had to change logl to log
overloaded to work with long double (just like this file does for
__CYGWIN__).
This is a definitely C++ construction, not C.
My system does have complex.h (which I think is the C99 version of C).
The only non-trivial functions it has is csqrt.
(I found this out by grepping the include directories.)
Stephen Montgomery-Smith
According to "spkg/installed", my system seems to have installed cephes.
These failures are happening in
sage -t -force_lib "devel/sage/sage/calculus/riemann.pyx"
Stephen Montgomery-Smith
> On 01/23/2012 08:12 AM, Dima Pasechnik wrote:
>> missing ccosh probably is a deficiency of libc/libm on your system.
>> Can you compile/link
>>
>> #include <math.h>
>> #include <complex.h>
>> int main() { double complex x=ccosh(1.); }
>>
>> on your system, and what extra libs does it need?
> My system does have complex.h (which I think is the C99 version of C).
> The only non-trivial functions it has is csqrt.
But on my Linux system, complex.h has a link to bits/cmathcalls.h, and
that does have ccosh. And ccosh is part of libm.
So I will have to figure out if I can make this work with FreeBSD.
Stephen Montgomery-Smith
Stephen Montgomery-Smith
> On 01/23/2012 12:34 PM, Jeroen Demeyer wrote:
>> On 2012-01-23 14:27, Stephen Montgomery-Smith wrote:
>>> "ccosh" not found seemed like a common error.
>> This might be solvable by installing cephes on FreeBSD. This is
>> included in Sage but only installed on Cygwin.
>>
>
> According to "spkg/installed", my system seems to have installed cephes.
But now that I look in cephes-2.8/spkg-install I see what you mean. I
will try building cephes.
Stephen Montgomery-Smith
> On 01/23/2012 12:34 PM, Jeroen Demeyer wrote:
>> On 2012-01-23 14:27, Stephen Montgomery-Smith wrote:
>>> "ccosh" not found seemed like a common error.
>> This might be solvable by installing cephes on FreeBSD. This is
>> included in Sage but only installed on Cygwin.
>>
>
> According to "spkg/installed", my system seems to have installed cephes.
OK, now I understand what you were trying to tell me.
So I modified it so that cephes now builds. It seems to help a little,
because in the log file for r-2.14.0.p1.log it says that it found ccosh,
when previously it said it didn't.
Nevertheless, I am still getting the same errors when I run
> sage -t -force_lib "devel/sage/sage/calculus/riemann.pyx"
I see in the source code that there are huge numbers of places where
CYGWIN is checked. So it is really hard for me to trace whether there
is a check somewhere else for CYGWIN that causes it to try cephes first
before looking in /usr/local/include.
Thanks, Stephen
Stephen Montgomery-Smith
http://www.sagemath.org/doc/installation/source.html
it says that "make -j4" is respected. This works really great when
building the source code.
But the documentation also suggests that it should be building in
parallel when creating the documentation? Should there by 4 invocations
of python working at once? Or is one python supposed to be running 4
threads?
Michael Orlitzky
This came up somewhere else recently, and this ticket was mentioned:
http://trac.sagemath.org/sage_trac/ticket/6495
If I remember correctly, the docs all build serially at the moment.