Re: Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Martin Albrecht
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
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
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
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
(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
I think, that is only the first occurence of the problem:
you cannot build the other libraries without first building omalloc.
Hans