Re: Re: [sage-devel] Re: sage-4.3.1.rc0 released!

0 views
Skip to first unread message

Martin Albrecht

unread,
Jan 22, 2010, 10:46:13 PM1/22/10
to sage-...@googlegroups.com, libsingular-devel
CC to [libsingular-devel] to make the Singular development team (which has
been incredibly helpful and supportive in the past!) aware of this discussion.

> >> I so wish you were right! The programs you refer to like Singular
> >> are very simple and tiny compared to Sage. If things were so easy as
> >> you think, somebody would already have set things up so one can do
> >> things that way. Nothing is stopping anyway from doing that now.
> >
> > Happens that Singular is a stumbling stone in the port of Sage to
> > Open Solaris 64 bit! As it comes to building libsingular I have no clue
> > at the moment.
> >
> > Jaap
>
> I'll help you on that, but I need to sort out the 'prereq' script and now
> feel I need to devote some time to trying to fix this issue created
> somewhere between 4.3 and 4.3.1, where the SPARC port got broken.
>
> It looks like there are plenty of patches to singular: spkg-install
> contains
>
> patch()
> {
> # work-around patches
> cp patches/mminit.cc src/kernel/
> cp patches/assert.h src/factory/
> cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
> cp patches/src.Singular.Makefile.in src/Singular/Makefile.in
> cp patches/Singular.libsingular.h src/Singular/libsingular.h
> cp patches/factory.GNUmakefile.in src/factory/GNUmakefile.in
> cp patches/libfac.charset.alg_factor.cc
> src/libfac/charset/alg_factor.cc cp patches/kernel.Makefile.in
> src/kernel/Makefile.in
> cp patches/Singular.Makefile.in src/Singular/Makefile.in
> cp patches/Singular.tesths.cc src/Singular/tesths.cc
> #cp patches/Singular.configure src/Singular/configure
> #cp patches/Singular.configure.in src/Singular/configure.in
> }
>
> I suspect some of them have GNUisms in them, though this does build 32-bit
> SPARC.

A lot of this is me being lazy and not submitting out fixes upstream. The
development model right now is that I patch whatever I deem necessary for
libsingular to work (e.g. include more header files etc.) and my changes are
then reviewed and (when accepted) applied upstream. This long list indicates,
that I should submit a batch of patches again.

Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de

Martin Albrecht

unread,
Jan 28, 2010, 7:31:58 PM1/28/10
to libsingu...@googlegroups.com
Sorry for replying to myself.

There seems to be an issue with the new Singular 3-1-0-9 on OpenSolaris.
Omalloc doesn't build anymore because of the "-pg" switch. I don't know if
that's a compiler bug or not. In any case, is there a magic option we can pass
to configure so it won't build the profiling version of omalloc?

See http://trac.sagemath.org/sage_trac/ticket/8059#comment:16 for details

Cheers,

Hans Schoenemann

unread,
Jan 29, 2010, 3:52:40 AM1/29/10
to libsingu...@googlegroups.com
The Opensolaris problems seems only to be a problem with
the compiler option -pg. The profiling versions
of the libary are not really needed, the folling patch to
omalloc/Makefile.in shall remove it from the default target.

Hans Schoenemann

--- Makefile.in (revision 12476)
+++ Makefile.in (working copy)
@@ -193,15 +193,13 @@
$(MKINSTALLDIRS) $(includedir)/singular
$(INSTALL) omalloc.h $(includedir)/singular

-install: all libomalloc_p.a
+install: all
$(MKINSTALLDIRS) $(libdir)
$(MKINSTALLDIRS) $(includedir)
$(INSTALL_DATA) libomalloc.a $(libdir)
$(RANLIB) $(libdir)/libomalloc.a
$(INSTALL_DATA) libomalloc_ndebug.a $(libdir)
$(RANLIB) $(libdir)/libomalloc_ndebug.a
- $(INSTALL_DATA) libomalloc_p.a $(libdir)
- $(RANLIB) $(libdir)/libomalloc_p.a
$(INSTALL_DATA) omalloc.o $(libdir)
$(INSTALL_DATA) omalloc_debug.o $(libdir)
$(INSTALL_DATA) omalloc.h $(includedir)
@@ -209,6 +207,10 @@
$(INSTALL_DATA) omlimits.h $(includedir)
$(INSTALL_DATA) mylimits.h $(includedir)

+install_all: install libomalloc_p.a
+ $(INSTALL_DATA) libomalloc_p.a $(libdir)
+ $(RANLIB) $(libdir)/libomalloc_p.a
+
install_min: libomalloc_ndebug.a omalloc.o
$(MKINSTALLDIRS) $(libdir)
$(MKINSTALLDIRS) $(includedir)

Hans Schoenemann

unread,
Jan 29, 2010, 4:21:19 AM1/29/10
to libsingu...@googlegroups.com
On a second thought:
also other libraries of singular build profiling versions
(and may also fail if the compiler does not understand -pg):
they need similiar patches of their Makefile.in
(libfac, factory and kernel)

Hans Schoenemann


Martin Albrecht

unread,
Jan 29, 2010, 4:39:28 AM1/29/10
to libsingu...@googlegroups.com, Jaap Spies

(CCing Jaap who reported the issue)

Strangely, the problem seems only to occur for omalloc, at least judging by
the report:

gcc -g -pg -O3 -I. -
I/export/home/jaap/Downloads/sage-4.3.2.alpha0/local/include -O2 -g -m64 -
I/export/home/jaap/Downloads/sage-4.3.2.alpha0/local/include -DHAVE_CONFIG_H -
c omBinPage.c -o omBinPage.op
/var/tmp//ccciayz2.s: Assembler messages:
/var/tmp//ccciayz2.s:31: Error: junk `@' after expression
/var/tmp//ccciayz2.s:110: Error: junk `@' after expression
/var/tmp//ccciayz2.s:183: Error: junk `@' after expression
/var/tmp//ccciayz2.s:270: Error: junk `@' after expression
/var/tmp//ccciayz2.s:477: Error: junk `@' after expression
/var/tmp//ccciayz2.s:805: Error: junk `@' after expression
/var/tmp//ccciayz2.s:1240: Error: junk `@' after expression
/var/tmp//ccciayz2.s:1718: Error: junk `@' after expression
/var/tmp//ccciayz2.s:2041: Error: junk `@' after expression
make[2]: *** [omBinPage.op] Error 1
make[2]: Leaving directory
`/export/home/jaap/Downloads/sage-4.3.2.alpha0/spkg/build/singular-3-1-0-9-20100125/src/omalloc'
make[1]: *** [install] Error 1
make[1]: Leaving directory
`/export/home/jaap/Downloads/sage-4.3.2.alpha0/spkg/build/singular-3-1-0-9-20100125/src'
make: ***
[/export/home/jaap/Downloads/sage-4.3.2.alpha0/local/bin/Singular-3-1-0] Error
2
Unable to build Singular.

Hans Schoenemann

unread,
Jan 29, 2010, 5:23:31 AM1/29/10
to libsingu...@googlegroups.com
> Strangely, the problem seems only to occur for omalloc, at least judging by
> the report....
I think, that is only the first occurence of the problem:
you cannot build the other libraries without first building omalloc.

Hans

Reply all
Reply to author
Forward
0 new messages