Prolem building Macaulay2 1.0
61 views
Skip to first unread message
gri6507
Jan 5, 2008, 7:10:07 PM1/5/08
to Macaulay2
I got the 1.0 version of Macaulay2 from SVN and am currenty trying to
build it. Unfortunately, I am running into problems building it up. I
get a seg fault at some point in during the make process (see below).
I'm not sure which other information I need to provide. Can someone
please suggest a possible solution or workaround?
cd ../../../../Macaulay2/regex && etags regex.c
make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/regex'
util/restart d/restart.tmp make -C d all
util/restart: running: make -C d all
make[2]: Entering directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/d'
Makefile:132: interp.dep: No such file or directory
Makefile:132: texmacs.dep: No such file or directory
Makefile:132: interface.dep: No such file or directory
Makefile:132: actors5.dep: No such file or directory
Makefile:132: actors4.dep: No such file or directory
Makefile:132: actors3.dep: No such file or directory
Makefile:132: actors2.dep: No such file or directory
Makefile:132: actors.dep: No such file or directory
Makefile:132: evaluate.dep: No such file or directory
Makefile:132: libfac.dep: No such file or directory
Makefile:132: objects.dep: No such file or directory
Makefile:132: struct.dep: No such file or directory
Makefile:132: GC.dep: No such file or directory
Makefile:132: util.dep: No such file or directory
Makefile:132: common.dep: No such file or directory
Makefile:132: convertr.dep: No such file or directory
Makefile:132: basic.dep: No such file or directory
Makefile:132: binding.dep: No such file or directory
Makefile:132: parser.dep: No such file or directory
Makefile:132: lex.dep: No such file or directory
Makefile:132: tokens.dep: No such file or directory
Makefile:132: engine.dep: No such file or directory
Makefile:132: gmp.dep: No such file or directory
Makefile:132: err.dep: No such file or directory
Makefile:132: stdiop.dep: No such file or directory
Makefile:132: getline.dep: No such file or directory
Makefile:132: stdio.dep: No such file or directory
Makefile:132: varnets.dep: No such file or directory
Makefile:132: nets.dep: No such file or directory
Makefile:132: ctype.dep: No such file or directory
Makefile:132: vararray.dep: No such file or directory
Makefile:132: varstrin.dep: No such file or directory
Makefile:132: strings.dep: No such file or directory
Makefile:132: system.dep: No such file or directory
Makefile:132: C.dep: No such file or directory
../c/scc1 -dep -J. ../../../../Macaulay2/d/C.d
make[2]: *** [C.dep] Segmentation fault (core dumped)
make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/d'
build it. Unfortunately, I am running into problems building it up. I
get a seg fault at some point in during the make process (see below).
I'm not sure which other information I need to provide. Can someone
please suggest a possible solution or workaround?
cd ../../../../Macaulay2/regex && etags regex.c
make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/regex'
util/restart d/restart.tmp make -C d all
util/restart: running: make -C d all
make[2]: Entering directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/d'
Makefile:132: interp.dep: No such file or directory
Makefile:132: texmacs.dep: No such file or directory
Makefile:132: interface.dep: No such file or directory
Makefile:132: actors5.dep: No such file or directory
Makefile:132: actors4.dep: No such file or directory
Makefile:132: actors3.dep: No such file or directory
Makefile:132: actors2.dep: No such file or directory
Makefile:132: actors.dep: No such file or directory
Makefile:132: evaluate.dep: No such file or directory
Makefile:132: libfac.dep: No such file or directory
Makefile:132: objects.dep: No such file or directory
Makefile:132: struct.dep: No such file or directory
Makefile:132: GC.dep: No such file or directory
Makefile:132: util.dep: No such file or directory
Makefile:132: common.dep: No such file or directory
Makefile:132: convertr.dep: No such file or directory
Makefile:132: basic.dep: No such file or directory
Makefile:132: binding.dep: No such file or directory
Makefile:132: parser.dep: No such file or directory
Makefile:132: lex.dep: No such file or directory
Makefile:132: tokens.dep: No such file or directory
Makefile:132: engine.dep: No such file or directory
Makefile:132: gmp.dep: No such file or directory
Makefile:132: err.dep: No such file or directory
Makefile:132: stdiop.dep: No such file or directory
Makefile:132: getline.dep: No such file or directory
Makefile:132: stdio.dep: No such file or directory
Makefile:132: varnets.dep: No such file or directory
Makefile:132: nets.dep: No such file or directory
Makefile:132: ctype.dep: No such file or directory
Makefile:132: vararray.dep: No such file or directory
Makefile:132: varstrin.dep: No such file or directory
Makefile:132: strings.dep: No such file or directory
Makefile:132: system.dep: No such file or directory
Makefile:132: C.dep: No such file or directory
../c/scc1 -dep -J. ../../../../Macaulay2/d/C.d
make[2]: *** [C.dep] Segmentation fault (core dumped)
make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/d'
Daniel R. Grayson
Jan 5, 2008, 7:46:12 PM1/5/08
to maca...@googlegroups.com, d...@math.uiuc.edu
Yup, there's not enough information in your email for us to see what's going on
to cause the segmentation fault.
I'd be glad to try to debug it for you. Perhaps we have access to a system
just like yours, or perhaps you could make an account for us on your system and
let us try it. What type of system is it? Does it have libgc already
installed? are you experienced with using a debugger to locate faults? If so,
you could compile the debug version (reconfigure it with --enable-debug) and
symbol tables and debugging information would be left in the binaries (such as
scc1) for proper debugging.
--
Daniel R. Grayson, Professor (retired, Emeritus)
Department of Mathematics
University of Illinois at Urbana-Champaign
www: http://www.math.uiuc.edu/~dan/
email: d...@math.uiuc.edu
us mail: 2409 S. Vine St., Urbana, IL 61801, USA
cell: +49-151-1072-7319 ( "+" -> your international dialing code )
phone: 217-367-6384 home (88.20224W, 40.08541N)
clock: my clock is CET = EST+6 = CST+7 = PST+9
> Date: Sat, 5 Jan 2008 16:10:07 -0800 (PST)
> Subject: [Macaulay2] Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
> I got the 1.0 version of Macaulay2 from SVN and am currenty trying to
> build it. Unfortunately, I am running into problems building it up. I
> get a seg fault at some point in during the make process (see below).
> I'm not sure which other information I need to provide. Can someone
> please suggest a possible solution or workaround?
...
> ../c/scc1 -dep -J. ../../../../Macaulay2/d/C.d
> make[2]: *** [C.dep] Segmentation fault (core dumped)
> make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/d'
gri6507
Jan 5, 2008, 8:21:01 PM1/5/08
to Macaulay2
Thank you for the response. I am actually trying to package up the
latest version of Macaulay2 into an RPM. My preferred development
environment is a clean virtual machine running TinyMe (http://
www.mypclinuxos.com/doku.php/tinyme:home) a flavor of PCLinuxOS
(http://www.pclinuxos.com). That being said, doing the type of remote
debugging you are suggesting would be difficult, but I can always
recreate the setup on my main machine if we decide to go that way.
To give you a bit of a background, my already system has
* gc 7.0
* NTL 5.4.1
* Singular Factory 3.0.2
* libfac 3.0.2
I built these RPMs to meet the requirements for M2 because I did not
want to compile all in one package. An interesting thing is that the
1.0 version of M2 detected my factory and libfac installs just fine,
but the latest SVN version 6066 did not (it complained about
SW_USE_NTL not being defined in factoryconfig.h, which it really
isn't; it's a const int declaration in factory.h)
My next step was going to be rebuilding with the --enable-debug flag
and try debugging with gdb. I'll post my results here next. In the
mean time, i'd love to hear any other suggestions you may have.
Thank you for the reply,
Paul.
P.S. in case you are wondering, I'm trying to pacakge up M2 into RPM
form so that I could finish packaging up SAGE into an RPM.
latest version of Macaulay2 into an RPM. My preferred development
environment is a clean virtual machine running TinyMe (http://
www.mypclinuxos.com/doku.php/tinyme:home) a flavor of PCLinuxOS
(http://www.pclinuxos.com). That being said, doing the type of remote
debugging you are suggesting would be difficult, but I can always
recreate the setup on my main machine if we decide to go that way.
To give you a bit of a background, my already system has
* gc 7.0
* NTL 5.4.1
* Singular Factory 3.0.2
* libfac 3.0.2
I built these RPMs to meet the requirements for M2 because I did not
want to compile all in one package. An interesting thing is that the
1.0 version of M2 detected my factory and libfac installs just fine,
but the latest SVN version 6066 did not (it complained about
SW_USE_NTL not being defined in factoryconfig.h, which it really
isn't; it's a const int declaration in factory.h)
My next step was going to be rebuilding with the --enable-debug flag
and try debugging with gdb. I'll post my results here next. In the
mean time, i'd love to hear any other suggestions you may have.
Thank you for the reply,
Paul.
P.S. in case you are wondering, I'm trying to pacakge up M2 into RPM
form so that I could finish packaging up SAGE into an RPM.
gri6507
Jan 6, 2008, 11:02:06 AM1/6/08
to Macaulay2
Ok, the debugging results are in.
Segfault happens on the yyinit() call shortly after the beginning of
main(). The actual segfault happens on the first call to
registerkeyword() function. This, in turn calls UniqueString("do"),
which calls UniqueStringN("do", len), but for whatever reason, len is
not defined. This, of course, when calls newnode1(), which calls
GC_debug_malloc(), which calls GC_malloc() which calls malloc()
segfaults because the size of the memory being malloced is incorrect.
My guess is that scc.h is missing #include <string.h>. I'll test that
theory next and post my results.
Paul.
Segfault happens on the yyinit() call shortly after the beginning of
main(). The actual segfault happens on the first call to
registerkeyword() function. This, in turn calls UniqueString("do"),
which calls UniqueStringN("do", len), but for whatever reason, len is
not defined. This, of course, when calls newnode1(), which calls
GC_debug_malloc(), which calls GC_malloc() which calls malloc()
segfaults because the size of the memory being malloced is incorrect.
My guess is that scc.h is missing #include <string.h>. I'll test that
theory next and post my results.
Paul.
gri6507
Jan 6, 2008, 11:55:09 AM1/6/08
to Macaulay2
Unfortunately, that was a bit of a red herring. It's not a prototype
issue. So, I ran valgrind on scc1. Here's the output.
gri6507@localhost:~/src/rpm/BUILD/macaulay2-svn6066/BUILD/normal/
Macaulay2/c>valgrind -v ./scc1
==2199== Memcheck, a memory error detector.
==2199== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et
al.
==2199== Using LibVEX rev 1606, a library for dynamic binary
translation.
==2199== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==2199== Using valgrind-3.2.0, a dynamic binary instrumentation
framework.
==2199== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et
al.
==2199==
--2199-- Command line
--2199-- ./scc1
--2199-- Startup, with flags:
--2199-- -v
--2199-- Contents of /proc/version:
--2199-- Linux version 2.6.18.8.tex5.lgc (vaughan@localhost) (gcc
version 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007)) #1 Thu May 10
11:55:36 WST 2007
--2199-- Arch and hwcaps: X86, x86-sse1-sse2
--2199-- Valgrind library directory: /usr/lib/valgrind
--2199-- Reading syms from /lib/ld-2.4.so (0x4000000)
--2199-- Reading syms from /home/gri6507/src/rpm/BUILD/macaulay2-
svn6066/BUILD/normal/Macaulay2/c/scc1 (0x8048000)
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck
(0x38000000)
--2199-- object doesn't have a symbol table
--2199-- object doesn't have a dynamic symbol table
--2199-- Reading suppressions file: /usr/lib/valgrind/default.supp
--2199-- REDIR: 0x4013A50 (index) redirected to 0x380277EB (???)
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/
vgpreload_core.so (0x401B000)
--2199-- object doesn't have a symbol table
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/
vgpreload_memcheck.so (0x401D000)
--2199-- object doesn't have a symbol table
==2199== WARNING: new redirection conflicts with existing -- ignoring
it
--2199-- new: 0x04013A50 (index ) R-> 0x04020080 index
--2199-- REDIR: 0x4013C60 (strlen) redirected to 0x4020130 (strlen)
--2199-- Reading syms from /usr/lib/libgc.so.1.0.3 (0x402D000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/i686/libm-2.4.so (0x405F000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/i686/libc-2.4.so (0x4084000)
--2199-- object doesn't have a symbol table
--2199-- Reading syms from /lib/i686/libpthread-2.4.so (0x41B1000)
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/libdl-2.4.so (0x41C5000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/libgcc_s-4.1.1.so.1 (0x41C9000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- REDIR: 0x40F0310 (memset) redirected to 0x4020420 (memset)
--2199-- REDIR: 0x40F0810 (memcpy) redirected to 0x4020BC0 (memcpy)
--2199-- REDIR: 0x40EF460 (rindex) redirected to 0x401FF60 (rindex)
==2199== Invalid read of size 4
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
==2199== Address 0x98 is not stack'd, malloc'd or (recently) free'd
==2199==
==2199== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==2199== Access not within mapped region at address 0x98
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
--2199-- REDIR: 0x40E8EA0 (free) redirected to 0x401EF2B (free)
==2199==
==2199== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from
1)
==2199==
==2199== 1 errors in context 1 of 1:
==2199== Invalid read of size 4
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
==2199== Address 0x98 is not stack'd, malloc'd or (recently) free'd
--2199--
--2199-- supp: 21 Fedora-Core-5-hack3-ld24
==2199==
==2199== IN SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1)
==2199==
==2199== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2199== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==2199==
==2199== All heap blocks were freed -- no leaks are possible.
--2199-- memcheck: sanity checks: 0 cheap, 1 expensive
--2199-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--2199-- memcheck: auxmaps: 0 searches, 0 comparisons
--2199-- memcheck: SMs: n_issued = 12 (192k, 0M)
--2199-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--2199-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--2199-- memcheck: SMs: max_undefined = 0 (0k, 0M)
--2199-- memcheck: SMs: max_defined = 25 (400k, 0M)
--2199-- memcheck: SMs: max_non_DSM = 12 (192k, 0M)
--2199-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--2199-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--2199-- memcheck: max shadow mem size: 496k, 0M
--2199-- translate: fast SP updates identified: 2,145
( 91.8%)
--2199-- translate: generic_known SP updates identified: 88 ( 3.7%)
--2199-- translate: generic_unknown SP updates identified: 102
( 4.3%)
--2199-- tt/tc: 3,475 tt lookups requiring 3,502 probes
--2199-- tt/tc: 3,475 fast-cache updates, 3 flushes
--2199-- transtab: new 1,636 (36,277 -> 612,110; ratio 168:10)
[0 scs]
--2199-- transtab: dumped 0 (0 -> ??)
--2199-- transtab: discarded 8 (172 -> ??)
--2199-- scheduler: 74,025 jumps (bb entries).
--2199-- scheduler: 0/1,987 major/minor sched events.
--2199-- sanity: 1 cheap, 1 expensive checks.
--2199-- exectx: 30,011 lists, 7 contexts (avg 0 per list)
--2199-- exectx: 22 searches, 15 full compares (681 per 1000)
--2199-- exectx: 0 cmp2, 46 cmp4, 0 cmpAll
Segmentation fault
issue. So, I ran valgrind on scc1. Here's the output.
gri6507@localhost:~/src/rpm/BUILD/macaulay2-svn6066/BUILD/normal/
Macaulay2/c>valgrind -v ./scc1
==2199== Memcheck, a memory error detector.
==2199== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et
al.
==2199== Using LibVEX rev 1606, a library for dynamic binary
translation.
==2199== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==2199== Using valgrind-3.2.0, a dynamic binary instrumentation
framework.
==2199== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et
al.
==2199==
--2199-- Command line
--2199-- ./scc1
--2199-- Startup, with flags:
--2199-- -v
--2199-- Contents of /proc/version:
--2199-- Linux version 2.6.18.8.tex5.lgc (vaughan@localhost) (gcc
version 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007)) #1 Thu May 10
11:55:36 WST 2007
--2199-- Arch and hwcaps: X86, x86-sse1-sse2
--2199-- Valgrind library directory: /usr/lib/valgrind
--2199-- Reading syms from /lib/ld-2.4.so (0x4000000)
--2199-- Reading syms from /home/gri6507/src/rpm/BUILD/macaulay2-
svn6066/BUILD/normal/Macaulay2/c/scc1 (0x8048000)
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck
(0x38000000)
--2199-- object doesn't have a symbol table
--2199-- object doesn't have a dynamic symbol table
--2199-- Reading suppressions file: /usr/lib/valgrind/default.supp
--2199-- REDIR: 0x4013A50 (index) redirected to 0x380277EB (???)
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/
vgpreload_core.so (0x401B000)
--2199-- object doesn't have a symbol table
--2199-- Reading syms from /usr/lib/valgrind/x86-linux/
vgpreload_memcheck.so (0x401D000)
--2199-- object doesn't have a symbol table
==2199== WARNING: new redirection conflicts with existing -- ignoring
it
--2199-- new: 0x04013A50 (index ) R-> 0x04020080 index
--2199-- REDIR: 0x4013C60 (strlen) redirected to 0x4020130 (strlen)
--2199-- Reading syms from /usr/lib/libgc.so.1.0.3 (0x402D000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/i686/libm-2.4.so (0x405F000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/i686/libc-2.4.so (0x4084000)
--2199-- object doesn't have a symbol table
--2199-- Reading syms from /lib/i686/libpthread-2.4.so (0x41B1000)
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/libdl-2.4.so (0x41C5000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- Reading syms from /lib/libgcc_s-4.1.1.so.1 (0x41C9000)
--2199-- object doesn't have a symbol table
==2199== Warning: zero-sized CIE/FDE but not at section end in DWARF2
CFI reading
--2199-- REDIR: 0x40F0310 (memset) redirected to 0x4020420 (memset)
--2199-- REDIR: 0x40F0810 (memcpy) redirected to 0x4020BC0 (memcpy)
--2199-- REDIR: 0x40EF460 (rindex) redirected to 0x401FF60 (rindex)
==2199== Invalid read of size 4
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
==2199== Address 0x98 is not stack'd, malloc'd or (recently) free'd
==2199==
==2199== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==2199== Access not within mapped region at address 0x98
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
--2199-- REDIR: 0x40E8EA0 (free) redirected to 0x401EF2B (free)
==2199==
==2199== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from
1)
==2199==
==2199== 1 errors in context 1 of 1:
==2199== Invalid read of size 4
==2199== at 0x4046821: GC_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x4039F7E: GC_debug_malloc (in /usr/lib/libgc.so.1.0.3)
==2199== by 0x8048B44: getmem (scc1.c:23)
==2199== by 0x8048B81: newnode1 (scc1.c:35)
==2199== by 0x804BAFF: UniqueStringN (dictionary.c:233)
==2199== by 0x80576CB: UniqueString (type.c:18)
==2199== by 0x806B2EA: registerkeyword (grammar.c:2837)
==2199== by 0x806B30F: yyinit (grammar.c:2841)
==2199== by 0x804905C: main (scc1.c:188)
==2199== Address 0x98 is not stack'd, malloc'd or (recently) free'd
--2199--
--2199-- supp: 21 Fedora-Core-5-hack3-ld24
==2199==
==2199== IN SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1)
==2199==
==2199== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2199== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==2199==
==2199== All heap blocks were freed -- no leaks are possible.
--2199-- memcheck: sanity checks: 0 cheap, 1 expensive
--2199-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--2199-- memcheck: auxmaps: 0 searches, 0 comparisons
--2199-- memcheck: SMs: n_issued = 12 (192k, 0M)
--2199-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--2199-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--2199-- memcheck: SMs: max_undefined = 0 (0k, 0M)
--2199-- memcheck: SMs: max_defined = 25 (400k, 0M)
--2199-- memcheck: SMs: max_non_DSM = 12 (192k, 0M)
--2199-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--2199-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--2199-- memcheck: max shadow mem size: 496k, 0M
--2199-- translate: fast SP updates identified: 2,145
( 91.8%)
--2199-- translate: generic_known SP updates identified: 88 ( 3.7%)
--2199-- translate: generic_unknown SP updates identified: 102
( 4.3%)
--2199-- tt/tc: 3,475 tt lookups requiring 3,502 probes
--2199-- tt/tc: 3,475 fast-cache updates, 3 flushes
--2199-- transtab: new 1,636 (36,277 -> 612,110; ratio 168:10)
[0 scs]
--2199-- transtab: dumped 0 (0 -> ??)
--2199-- transtab: discarded 8 (172 -> ??)
--2199-- scheduler: 74,025 jumps (bb entries).
--2199-- scheduler: 0/1,987 major/minor sched events.
--2199-- sanity: 1 cheap, 1 expensive checks.
--2199-- exectx: 30,011 lists, 7 contexts (avg 0 per list)
--2199-- exectx: 22 searches, 15 full compares (681 per 1000)
--2199-- exectx: 0 cmp2, 46 cmp4, 0 cmpAll
Segmentation fault
Daniel R. Grayson
Jan 6, 2008, 4:40:45 PM1/6/08
to maca...@googlegroups.com, d...@math.uiuc.edu, mi...@math.cornell.edu
> Date: Sat, 5 Jan 2008 17:21:01 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
> Thank you for the response. I am actually trying to package up the
> latest version of Macaulay2 into an RPM.
> latest version of Macaulay2 into an RPM.
...
Is there something wrong with the RPM's we provide on the web site?
gri6507
Jan 6, 2008, 7:18:45 PM1/6/08
to Macaulay2
> Is there something wrong with the RPM's we provide on the web site?
It's not that there is something wrong, it's just that I am trying to
pacakge it up for redistribution in an RPM based Linux distro. In
other words, I need to start from an SRPM. I didn't see one on the
website and the most recent version I found on the web was quite old.
Daniel R. Grayson
Jan 6, 2008, 7:25:33 PM1/6/08
to maca...@googlegroups.com
Oh! I was wondering whether there was a reason for us to create a source RPM.
I guess there is!
I propose we collaborate on automating, at this end, the production of a source
RPM. Then anyone who checks out our source code can create the source RPM, at
any time in the future.
=============================================================================
> Date: Sun, 6 Jan 2008 16:18:45 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
gri6507
Jan 7, 2008, 9:37:12 AM1/7/08
to Macaulay2
> I propose we collaborate on automating, at this end, the production of a source
> RPM. Then anyone who checks out our source code can create the source RPM, at
> any time in the future.
I can gladly send you my current version of the SRPM I used to
> RPM. Then anyone who checks out our source code can create the source RPM, at
> any time in the future.
(attempt to) create by RPM. However, since you already have RPMs
created, that probably means that you already have some SRPMs too.
There shouldn't be much more "autopmation" required. Just make sure to
post a link to it.
Your SRPM actually may be the answer to my original problem. Does it
contain some patches? I'm still trying to figure out why the malloc()
call is failing in scc1 executable. Unfortunately, I'm not closer to
figuring it out yet :-(
Daniel R. Grayson
Jan 7, 2008, 5:42:02 PM1/7/08
to maca...@googlegroups.com
Nope, I made the binary RPM's "manually", by an automated procedure, using
rpmbuild. You can see how it's done in distributions/rpm/Makefile.in.
> Date: Mon, 7 Jan 2008 06:37:12 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
gri6507
Jan 7, 2008, 10:23:39 PM1/7/08
to Macaulay2
I may have figured it out. Going on the hunch that it was GC_malloc()
that was segfaulting, I took a guess that the problem was with the way
I build GC. So, I rebuilt it with a few additional flags (last three
configure options and new CFLAGS definition)
CFLAGS=-DGC_DEBUG %configure2_5x \
--enable-threads=pthreads \
--enable-cplusplus \
--enable-static \
--enable-shared \
--enable-redirect-malloc \
--enable-gc-debug \
--enable-gc-assertions
This got me through the M2 build process, although it keeps
complaining at me with a seemingly benign warning "GC Warning: Failed
to find libpthread.so text mapping: Expect crash" that never seemed to
fulfill itself.
Only then did I remember that there is a readme inside M2 describing
how to build the dependencies. That brought me to rebuild everything
with
CFLAGS="-DALL_INTERIOR_POINTERS -DLARGE_CONFIG" %configure2_5x \
--enable-threads=pthreads \
--enable-cplusplus \
--enable-static \
--enable-shared \
--enable-redirect-malloc \
--enable-thread-local-alloc \
--enable-parallel-mark
And now, things seems to be much happier (except for that and a number
of other warnings)! In the end, it was all just another case of "user
error". Unfortunately, even now, the compile process still crashed
(after well over 1 hour) with the following message
../../../../Macaulay2/m2/debugging.m2:4:17:(0):[10]: 1 error(s)
occurred running example files
../../../../Macaulay2/m2/html.m2:717:40:(0):[9]: --back trace--
../../../../Macaulay2/m2/methods.m2:93:80:(0):[8]: --back trace--
../../../../Macaulay2/m2/option.m2:8:8:(0):[7]: --back trace--
../../../../Macaulay2/m2/html.m2:533:6:(0):[6]: --back trace--
../../../../Macaulay2/m2/methods.m2:93:80:(0):[5]: --back trace--
../../../../Macaulay2/m2/option.m2:8:8:(0):[4]: --back trace--
a string:1:1:(1):[3]: --back trace--
../../../../Macaulay2/m2/methods.m2:299:22:(0):[3]: --back trace--
startup.m2:467:33:(0):[1]: --back trace--
startup.m2:552:1:(0):[0]: --back trace--
make[2]: *** [install-others] Error 1
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2'
make: *** [install] Error 2
make: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/BUILD/
normal'
Any thoughts about this problems?
that was segfaulting, I took a guess that the problem was with the way
I build GC. So, I rebuilt it with a few additional flags (last three
configure options and new CFLAGS definition)
CFLAGS=-DGC_DEBUG %configure2_5x \
--enable-threads=pthreads \
--enable-cplusplus \
--enable-static \
--enable-shared \
--enable-redirect-malloc \
--enable-gc-debug \
--enable-gc-assertions
This got me through the M2 build process, although it keeps
complaining at me with a seemingly benign warning "GC Warning: Failed
to find libpthread.so text mapping: Expect crash" that never seemed to
fulfill itself.
Only then did I remember that there is a readme inside M2 describing
how to build the dependencies. That brought me to rebuild everything
with
CFLAGS="-DALL_INTERIOR_POINTERS -DLARGE_CONFIG" %configure2_5x \
--enable-threads=pthreads \
--enable-cplusplus \
--enable-static \
--enable-shared \
--enable-redirect-malloc \
--enable-thread-local-alloc \
--enable-parallel-mark
And now, things seems to be much happier (except for that and a number
of other warnings)! In the end, it was all just another case of "user
error". Unfortunately, even now, the compile process still crashed
(after well over 1 hour) with the following message
../../../../Macaulay2/m2/debugging.m2:4:17:(0):[10]: 1 error(s)
occurred running example files
../../../../Macaulay2/m2/html.m2:717:40:(0):[9]: --back trace--
../../../../Macaulay2/m2/methods.m2:93:80:(0):[8]: --back trace--
../../../../Macaulay2/m2/option.m2:8:8:(0):[7]: --back trace--
../../../../Macaulay2/m2/html.m2:533:6:(0):[6]: --back trace--
../../../../Macaulay2/m2/methods.m2:93:80:(0):[5]: --back trace--
../../../../Macaulay2/m2/option.m2:8:8:(0):[4]: --back trace--
a string:1:1:(1):[3]: --back trace--
../../../../Macaulay2/m2/methods.m2:299:22:(0):[3]: --back trace--
startup.m2:467:33:(0):[1]: --back trace--
startup.m2:552:1:(0):[0]: --back trace--
make[2]: *** [install-others] Error 1
make[2]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2/packages'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/
BUILD/normal/Macaulay2'
make: *** [install] Error 2
make: Leaving directory `/home/gri6507/src/rpm/BUILD/macaulay2/BUILD/
normal'
Any thoughts about this problems?
Daniel R. Grayson
Jan 7, 2008, 10:38:05 PM1/7/08
to maca...@googlegroups.com
We've never compiled gc with pthreads enabled, so doing so might be related to
the error message about "libpthread.so text mapping."
Nowadays we have code that automatically compiles the libraries, if they aren't
found, so if you want to see the options we really currently compile gc with,
look in libraries/gc.
To figure out this one:
../../../../Macaulay2/m2/debugging.m2:4:17:(0):[10]: 1 error(s) occurred running example files
you must look further up in the output for the error that occurred. It doesn't
stop the make process immediately, because often we are able to fix more than
one such bug at a time. You will find the output and the input for the example
in files.
At the top of the build directory "make help" will show you how to append an
option to continue even if there is an error in an example file, but of course,
we try to avoid that.
gri6507
Jan 8, 2008, 10:21:26 PM1/8/08
to Macaulay2
The reason I compiled GC with pthread support is to keep compatibility
with the previous existing version of the library in our distribution.
I believe the warning is bening, possibly caused by not building
pthreads with -g (this is just a guess, but seems plausible).
As for the example problem, I rebuilt with IgnoreExampleErrors=true
and everything seems to be in order now.
Many thanks for all of your help! Please let me know if you'd like to
see my SRPM to get you started on your automation process.
P.S. the automatic building of dependent libraries is an excellent
idea for a regular build process. However, such a notion is uncommon,
or at the very least new, in the SRPM community. That is why I built
all of the dependencies as stand alone RPMs.
P.P.S. One more question. When configure runs it checks for the
presence of factory.h and then another check for factoryconf.h. The
latter check tries to validate that SW_USE_NTL is defined in
factoryconf.h. In fact, in v3.0.2 and 3.0.3 it is defined in
factory.h. I'm not sure what is the best way to address this in your
configure.ac. For now, I simply commented that check out.
with the previous existing version of the library in our distribution.
I believe the warning is bening, possibly caused by not building
pthreads with -g (this is just a guess, but seems plausible).
As for the example problem, I rebuilt with IgnoreExampleErrors=true
and everything seems to be in order now.
Many thanks for all of your help! Please let me know if you'd like to
see my SRPM to get you started on your automation process.
P.S. the automatic building of dependent libraries is an excellent
idea for a regular build process. However, such a notion is uncommon,
or at the very least new, in the SRPM community. That is why I built
all of the dependencies as stand alone RPMs.
P.P.S. One more question. When configure runs it checks for the
presence of factory.h and then another check for factoryconf.h. The
latter check tries to validate that SW_USE_NTL is defined in
factoryconf.h. In fact, in v3.0.2 and 3.0.3 it is defined in
factory.h. I'm not sure what is the best way to address this in your
configure.ac. For now, I simply commented that check out.
Daniel R. Grayson
Jan 17, 2008, 10:44:31 AM1/17/08
to maca...@googlegroups.com, d...@math.uiuc.edu
I encountered exactly the same problem on another machine last week, so I just
turned off pthreads entirely in the gc configuration.
I'm not sure the "redirect-malloc" option below is a great idea, but I suppose
it can't hurt. Does it matter for you?
> Date: Mon, 7 Jan 2008 19:23:39 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
...
Daniel R. Grayson
Jan 17, 2008, 11:13:18 AM1/17/08
to maca...@googlegroups.com, d...@math.uiuc.edu
> Date: Tue, 8 Jan 2008 19:21:26 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
...
> P.P.S. One more question. When configure runs it checks for the
> presence of factory.h and then another check for factoryconf.h. The
> latter check tries to validate that SW_USE_NTL is defined in
> factoryconf.h. In fact, in v3.0.2 and 3.0.3 it is defined in
> factory.h. I'm not sure what is the best way to address this in your
> configure.ac. For now, I simply commented that check out.
I guess it's been a while since I've run the configure script in an environment
where all the libraries are already installed. To test the configure script in
such an environment, I should run it after all the libraries are built with
M2/BUILD/u123/normal/libraries/final/usr/lib/Macaulay2/Core/lib/
M2/BUILD/u123/normal/libraries/final/usr/lib/Macaulay2/Core/include/
visible!
I'll add that test as part of "make check".
Thanks!
Daniel R. Grayson
Feb 9, 2008, 6:17:27 PM2/9/08
to maca...@googlegroups.com
I never replied to you about this, as we have been working hard at getting 1.1
out. Are you still having trouble?
> Date: Sun, 6 Jan 2008 08:55:09 -0800 (PST)
> Subject: [Macaulay2] Re: Prolem building Macaulay2 1.0
> From: gri6507 <gri...@gmail.com>
> To: Macaulay2 <maca...@googlegroups.com>
> Reply-To: maca...@googlegroups.com
>
>
> Unfortunately, that was a bit of a red herring. It's not a prototype
> issue. So, I ran valgrind on scc1. Here's the output.
...
gri6507
Mar 6, 2008, 8:18:21 PM3/6/08
to Macaulay2
I'm going to find out soon. I'm rebuilding M2 v1.1 right now with my
original libgc. I'll post my results here when the build completes.
original libgc. I'll post my results here when the build completes.
gri6507
Mar 8, 2008, 9:44:42 PM3/8/08
to Macaulay2
Well, after rebuilding Macaulay2 v1.1 with my original GC v7.0, I
still get the same segfault that I was experiencing originally. After
doing some more googling, I finally stumbled across what I think is a
similar problem (see http://bugs.gentoo.org/show_bug.cgi?id=195335).
The only problem is that their proposed solution doesn't make sense in
terms of libgc build options; so, bot being much of a Gentoo user, I'm
guessing that the solution is related to Gentoo settings. I sent an
email to the person who reported this solution asking them if they
know what this means as far as the build options go. I'll post back
when/if I hear something back.
still get the same segfault that I was experiencing originally. After
doing some more googling, I finally stumbled across what I think is a
similar problem (see http://bugs.gentoo.org/show_bug.cgi?id=195335).
The only problem is that their proposed solution doesn't make sense in
terms of libgc build options; so, bot being much of a Gentoo user, I'm
guessing that the solution is related to Gentoo settings. I sent an
email to the person who reported this solution asking them if they
know what this means as far as the build options go. I'll post back
when/if I hear something back.
gri6507
Mar 8, 2008, 10:46:02 PM3/8/08
to Macaulay2
It looks like the problem has been correctly identified as libgc. I
just rebuild libgc v7.1alpha3-080224 and there are no more issues with
Macaulay2 builds! I don't know what the problem was, but it seems like
it's been already fixed in the new version of libgc.
just rebuild libgc v7.1alpha3-080224 and there are no more issues with
Macaulay2 builds! I don't know what the problem was, but it seems like
it's been already fixed in the new version of libgc.
Daniel R. Grayson
Mar 8, 2008, 11:30:31 PM3/8/08
to maca...@googlegroups.com
I'm glad it's working for you now. Is that still a "TinyMe" system you're
using?
Paul Grinberg
Mar 10, 2008, 7:49:02 AM3/10/08
to maca...@googlegroups.com
Yes, it is (and of course, TinyMe is just one of a number of remasters of PCLinuxOS). However, this issue was definitely not limited to this distribution. As I posted earlier, this same issue was seen on Gentoo, and quite probably other platforms. After all, the issue was the fundamental codebase of libgc which had significant rework in the pthreads section of code between 7.0 and 7.1alpha3 releases.
Daniel R. Grayson
Mar 10, 2008, 10:00:28 AM3/10/08
to maca...@googlegroups.com
So you are using libgc version 7.1alpha3. Libgc 7.0 is what we've been using.
A release of libgc with "alpha" in the name can indicate that it contains new
code that may not work. Which version of libgc do gentoo and tinyme come with?
Paul Grinberg
Mar 10, 2008, 1:58:24 PM3/10/08
to maca...@googlegroups.com
I cannot vouch for Gentoo, but based on my understanding of their bug report and my discussions with the bug submitter, they are using libgc v7.0.
TinyMe (and all of its siblings) used to use libgc v6.x (I can't recall the exact number) prior to me needing v7.0 for macaulay. So, I compiled v7.0 with the standard set of switches (see my earlier post in this thread) which caused Macaulay2 build process to die with a segfault. I later rebuilt libgc with the modified set of switches (again see my earlier post) and that made Macaulya2 build successfully, but caused other programs that link against libgc (i.e inkscape) to die with a segfault. Since my discuvery of the pthreads issue in libgc v7.0, I have rebuilt v7.1alpha3 with standard options and now all programs including M2 and Inkscape work without segfaults.
I agree with you that using the "alpha" versions is a bit scary, but at least they no longer cause segfaults. The way I look at it is that the alpha version is basically v7.0 with lots of patches :-)
TinyMe (and all of its siblings) used to use libgc v6.x (I can't recall the exact number) prior to me needing v7.0 for macaulay. So, I compiled v7.0 with the standard set of switches (see my earlier post in this thread) which caused Macaulay2 build process to die with a segfault. I later rebuilt libgc with the modified set of switches (again see my earlier post) and that made Macaulya2 build successfully, but caused other programs that link against libgc (i.e inkscape) to die with a segfault. Since my discuvery of the pthreads issue in libgc v7.0, I have rebuilt v7.1alpha3 with standard options and now all programs including M2 and Inkscape work without segfaults.
I agree with you that using the "alpha" versions is a bit scary, but at least they no longer cause segfaults. The way I look at it is that the alpha version is basically v7.0 with lots of patches :-)
Daniel R. Grayson
Mar 11, 2008, 9:58:35 AM3/11/08
to maca...@googlegroups.com
Would it be worthwhile creating a gentoo portage source package for Macaulay2?
Does tinyme use the same portage repository that gentoo uses?
Paul Grinberg
Mar 11, 2008, 11:57:42 AM3/11/08
to maca...@googlegroups.com
TinyMe is an RPM based distro. I created an RPM for Macaulay2 for our distribution (please let me know if you'd like the srpm). I cannot say much about Gentoo because I am really unfamiliar with it. The only reason I referred to it is because they experienced the same problem as I did.
Daniel R. Grayson
Mar 11, 2008, 12:55:13 PM3/11/08
to maca...@googlegroups.com
I see. If you post the srpm somewhere, I can link from our web page to yours.
Similarly, if they let you post the rpm in the main tinyme repository, let me
know.
Thanks!
> Date: Tue, 11 Mar 2008 11:57:42 -0400
> From: "Paul Grinberg" <gri...@gmail.com>
Paul Grinberg
Mar 19, 2008, 7:57:28 AM3/19/08
to maca...@googlegroups.com
Sorry for the slight delay. I was waiting for the new Macaulay package to hit the public mirrors. Now that it has, you can find the SRPM at http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/SRPMS.extra/macaulay2-1.1-1pclos2007.src.rpm and the RPM at
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-1.1-1pclos2007.i586.rpm
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-doc-1.1-1pclos2007.i586.rpm
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-emacs-1.1-1pclos2007.i586.rpm
Of course, all other (S)RPMs needed by Macaulay are also in these directories (or their equivalents like *.main and *.testing)
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-1.1-1pclos2007.i586.rpm
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-doc-1.1-1pclos2007.i586.rpm
http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/RPMS.extra/macaulay2-emacs-1.1-1pclos2007.i586.rpm
Of course, all other (S)RPMs needed by Macaulay are also in these directories (or their equivalents like *.main and *.testing)
Reply all
Reply to author
Forward
0 new messages