On 06/29/10 01:26 PM, Martin Albrecht wrote:
I suspect the ONLY sensible way to do that would be to drop in new
Singular, delete all record of all the patches to singular package, and
create new patches as and when needed.
You suspect wrong. A new Singular SPKG is available in the ticket I referenced
in this thread which takes care of almost every of those patches.
Good to hear I am wrong.
<ship>
I doubt many of these issues have been reported upstream.
Again you are wrong. ALMOST ALL these issues (except one) have been reported
upstream and ALL of them have been accepted upstream making our patches
unnecessary.
Sounds like you are doing a good job of maintaining it then.
Have you any ideas how I might build this on OpenSolaris x64 as a 64-bit binary?
(I'd also like to get it to work as a SPARC 64-bit binary)
I constantly get this problem after about 5 minutes of building.
/usr/bin/ginstall -c -s gen_test
/export/home/drkirkby/clean/sage-4.5.alpha0/local/bin
/usr/bin/ginstall -c -s LLL
/export/home/drkirkby/clean/sage-4.5.alpha0/local/bin
make[1]: Leaving directory
`/export/home/drkirkby/clean/sage-4.5.alpha0/spkg/build/singular-3.1.0.4.p8/src/IntegerProgramming'
echo "* do not forget to install Singular-3-1-0-share.tar.gz"
* do not forget to install Singular-3-1-0-share.tar.gz
cd Singular; make libsingular
make[1]: Entering directory
`/export/home/drkirkby/clean/sage-4.5.alpha0/spkg/build/singular-3.1.0.4.p8/src/Singular'
g++ -O2 -g -m64 -fPIC -pipe -I. -I../kernel
-I/export/home/drkirkby/clean/sage-4.5.alpha0/local/include
-I/export/home/drkirkby/clean/sage-4.5.alpha0/local/include
-I/export/home/drkirkby/clean/sage-4.5.alpha0/local/include -O2 -g -m64
-fno-implicit-templates -DNDEBUG -DOM_NDEBUG -Dix86_SunOS -DHAVE_CONFIG_H
-DLIBSINGULAR \
-o libsingular-tesths.o \
-c tesths.cc
g++ -o libsingular.so \
libsingular-tesths.o iparith.o mpsr_Tok.o claptmpl.o \
grammar.o scanner.o attrib.o eigenval_ip.o extra.o fehelp.o feOpt.o ipassign.o
ipconv.o ipid.o iplib.o ipprint.o ipshell.o lists.o sdb.o fglm.o interpolation.o
silink.o subexpr.o janet.o wrapper.o libparse.o sing_win.o gms.o pcv.o maps_ip.o
walk.o walk_ip.o cntrlc.o misc.o calcSVD.o slInit_Static.o mpsr_Put.o
mpsr_PutPoly.o mpsr_GetPoly.o mpsr_sl.o mpsr_Get.o mpsr_GetMisc.o mpsr_Error.o
ndbm.o sing_dbm.o -lkernel -L../kernel -L../factory -L../libfac
-L/export/home/drkirkby/clean/sage-4.5.alpha0/local/lib -lsingfac -lsingcf -lntl
-lreadline -lgmp -lomalloc
ld: fatal: file libsingular-tesths.o: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to libsingular.so
collect2: ld returned 1 exit status
make[1]: *** [libsingular] Error 1
make[1]: Leaving directory
`/export/home/drkirkby/clean/sage-4.5.alpha0/spkg/build/singular-3.1.0.4.p8/src/Singular'
make: *** [libsingular] Error 2
Unable to build Singular.
real 5m56.169s
user 5m42.646s
sys 0m18.352s
sage: An error occurred while installing singular-3.1.0.4.p8
No amount of hacking I can find will get the necessary -m64 option into the last
link phase.
Someone added a target
ifeq ($(SINGUNAME),ix86-SunOS)
SO_SUFFIX = so
LIBSINGULAR_FLAGS = -shared
LIBSINGULAR_LIBS = -lsingfac -lsingcf -lntl -lreadline -lgmp -lomalloc
endif
but I don't know if that is being used or not. out of desperation I added -m64
on both of those lines
ifeq ($(SINGUNAME),ix86-SunOS)
SO_SUFFIX = so
LIBSINGULAR_FLAGS = -shared -m64
LIBSINGULAR_LIBS = -lsingfac -lsingcf -lntl -lreadline -lgmp -lomalloc -m64
endif
but it seems to be to no avail. It makes me think that target is not being used.
But what target is??
The file g++ is complaining about
spkg/build/singular-3.1.0.4.p8/src/Singular/libsingular-tesths.o:
*IS* a 64-bit object file, which it should be. But g++ is not seeing any -m64
option, so I assume it is assuming anything 64-bit is wrong.
Any ideas how I get a '-m64' to that compile line, so g++ does not balk at a
64-bit object, but actually tries to link them?
There
Dave
The one remaining issue is:
--- ../src/factory/assert.h 2009-11-02 10:12:22.000000000 +0000
+++ assert.h 2010-01-25 18:05:19.164005794 +0000
@@ -127,3 +127,13 @@
#define PVIRT_CHARCC(msg) = 0
#endif /* NOASSERT */
/* }}} */
+
+
+
+/* SAGE hack: This is *critically* needed to compile on some systems
+ for which the logic above is broken. Obviously it defeates the
+ purpose of assert here, but at least it means that the code compiles.
+*/
+#ifndef assert
+#define assert
+#endif
While it is a bit vague which these systems are at least it is sufficiently
documented why it is there. I'm confident we can remove this patch at Sage
Days in Kaiserslautern where the likely author of that patch (William), the
Singular team and myself (the maintainer of said SPKG) will be present.
Yes, as always things can be improved, but that is at least some documentation.
Martin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
