Opened 9 years ago

Closed 9 years ago

#12841 closed enhancement (fixed)

update M4RIE to newest upstream release

Reported by: malb Owned by: tbd
Priority: major Milestone: sage-5.3
Component: packages: standard Keywords:
Cc: Merged in: sage-5.3.beta0
Authors: Martin Albrecht Reviewers: Simon King, Jeroen Demeyer, Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #12840 Stopgaps:

Status badges

Description (last modified by malb)

M4RIE-20120415's main improvement over the version we currently have in Sage is that it is much much faster for degrees 4 <= e <= 8 and bugfixes.

Install: http://sage.math.washington.edu/home/malb/spkgs/libm4rie-20120613.spkg

Apply: trac_12841_m4rie_new_version.patch

Attachments (1)

trac_12841_m4rie_new_version.patch (8.9 KB) - added by malb 9 years ago.

Download all attachments as: .zip

Change History (67)

Changed 9 years ago by malb

comment:1 Changed 9 years ago by malb

  • Description modified (diff)

comment:2 Changed 9 years ago by malb

  • Dependencies set to #12840

comment:3 Changed 9 years ago by malb

  • Description modified (diff)

comment:4 Changed 9 years ago by malb

  • Status changed from new to needs_review

comment:5 Changed 9 years ago by malb

Note that the SPKG is based on #12821

comment:6 follow-up: Changed 9 years ago by awebb

I get an error with SAGE_CHECK on

FAIL: test_ple
===================
5 of 5 tests failed
===================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'

This is on Ubuntu 12.04 (32 bit) on vmware in Windows 7. gcc version 4.6.3 (Ubuntu/Linaro? 4.6.3-1ubuntu4)

I got this with the previous package as well.

adam

comment:7 in reply to: ↑ 6 Changed 9 years ago by malb

Replying to awebb:

I get an error with SAGE_CHECK on

FAIL: test_ple
===================
5 of 5 tests failed
===================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'

This is on Ubuntu 12.04 (32 bit) on vmware in Windows 7. gcc version 4.6.3 (Ubuntu/Linaro? 4.6.3-1ubuntu4)

I got this with the previous package as well.

adam

Hi, unfortunately, that error message doesn't say much more than that there were errors.

  • The log should contain more detailed information, can you post this?
  • Also, by previous package you mean version 20111004?

comment:8 Changed 9 years ago by awebb

Do I just use the spkg above or do I need to apply the patch as well?

I have tried with libm4rie-20111004.p2.spkg and libm4rie-20111004.p3.spkg and got the same error. The log doesn't have any details at all. The error occurs during the make check-TESTS portion of the build. It just lists off a pile of tests and ends each section with things like FAIL: test_trsm. The odd part is that there are no fail messages anywhere else.

The home directories are not yet present on sage.math.washinton.edu but once they are I will upload the log file.

comment:9 Changed 9 years ago by malb

I fixed the issue in https://bitbucket.org/malb/m4rie/changeset/81d352a8aade and replaced the SPKG with a version with this fix applied.

comment:10 Changed 9 years ago by awebb

I tried again and got the same result. The log is at http://sage.math.washington.edu/home/awebb/libm4rie-20120415.log. I see anything useful in the log however.

comment:11 Changed 9 years ago by awebb

correction: I Don't see anything in the log that is useful. A.

comment:12 Changed 9 years ago by malb

Argh, that's because I uploaded the wrong file again. I fixed it and replaced the file.

comment:13 Changed 9 years ago by awebb

It looks like it worked. At least it built. I now have a ppl problem but that might have already been reported.

comment:14 follow-up: Changed 9 years ago by jdemeyer

  • Status changed from needs_review to needs_work

The new spkg wants to run autoheader. This probably means that upstream should run autoreconf before shipping their sources.

Making install in .
make[1]: Entering directory `/usr/local/src/sage-5.0.beta13/spkg/build/libm4rie-20120415/src'
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /usr/local/src/sage-5.0.beta13/spkg/build/libm4rie-20120415/src/missing --run autoheader)
rm -f src/stamp-h1
touch src/config.h.in

comment:15 Changed 9 years ago by jdemeyer

This is exactly the same problem which I already fixed once in #12501.

comment:16 in reply to: ↑ 14 Changed 9 years ago by malb

Replying to jdemeyer:

The new spkg wants to run autoheader. This probably means that upstream should run autoreconf before shipping their sources.

Upstream does that: https://bitbucket.org/malb/m4ri-scripts/src/tip/release.py#cl-35 but I added a touch configure afterwards. I also touched configure in the SPKG linked above.

comment:17 Changed 9 years ago by jdemeyer

  • Work issues set to autoheader

Are you sure you updated the spkg correctly? I still get exactly the same problem as I reported before.

comment:18 Changed 9 years ago by malb

On which box does this happen, I get on sage.math:

./sage-5.0.beta13-m4rie/sage -f ~/spkgs/libm4rie-20120415.spkg 
Calling sage-spkg on '/home/malb/spkgs/libm4rie-20120415.spkg'
libm4rie-20120415
====================================================
Extracting package /home/malb/spkgs/libm4rie-20120415.spkg
-rw-r--r-- 1 malb malb 401369 2012-04-15 07:03 /home/malb/spkgs/libm4rie-20120415.spkg
Finished extraction
****************************************************
Host system:
Linux sage.math.washington.edu 2.6.24-28-server #1 SMP Fri Feb 11 18:08:32 UTC 2011 x86_64 GNU/Linux
****************************************************
C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/scratch/malb/sage-5.0.beta13-m4rie/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --prefix=/scratch/malb/sage-5.0.beta13/local --with-local-prefix=/scratch/malb/sage-5.0.beta13/local --with-gmp=/scratch/malb/sage-5.0.beta13/local --with-mpfr=/scratch/malb/sage-5.0.beta13/local --with-mpc=/scratch/malb/sage-5.0.beta13/local --with-system-zlib --disable-multilib  
Thread model: posix
gcc version 4.6.3 (GCC) 
****************************************************
checking build system type... x86_64-unknown-linux-gnu

comment:19 Changed 9 years ago by jdemeyer

This was on boxen.math. Anyway, the relevant file which should be touched is config.h.in (not configure)

comment:20 follow-up: Changed 9 years ago by malb

I've updated the SPKG accordingly and my release script (for future releases)

comment:21 in reply to: ↑ 20 Changed 9 years ago by SimonKing

Replying to malb:

I've updated the SPKG accordingly and my release script (for future releases)

Does that mean the ticket needs review? Or still needs work?

comment:22 Changed 9 years ago by malb

  • Status changed from needs_work to needs_review

Thanks, it needs review

comment:23 Changed 9 years ago by SimonKing

The ticket description mentions bug fixes. What are they?

comment:24 follow-up: Changed 9 years ago by malb

The bugfixes mainly concern the testsuite: https://bitbucket.org/malb/m4rie/changesets

  • !81d352a8aade reserve enough pointers for finite fields in testsuite
  • !8245cd046d86 removed a bit of dead code scan-build reported
  • !b81b9649e2d1 use unsigned ints for degrees everywhere
  • !ad8e309640e3 make sure the canary does not set bits which are expected to be zero (e.g. in lockup tables)
  • !f6f4b011dbe3 fixed a memleak
  • !dfacf106f205 bitmasks should be unsigned
  • !a3087ea586d7 fixed memleak in test_smallops
  • !02f7dfe20ff5 replaced nonstandard STRING(x) with #x
  • !9d23a80fa589 remove -lntl, it's not needed
  • !f104847ecea0 using less temporary memory for Karatsuba for GF(24)
  • !bd90f880f4a8 saving memory in karatsuba multiplication
  • !548023a54d9e use rpath for test_* to make sure the right version of the library is used
  • !559610e11d7e unified strassen cutoff

comment:25 in reply to: ↑ 24 ; follow-ups: Changed 9 years ago by SimonKing

Replying to malb:

The bugfixes mainly concern the testsuite:

I didn't install the package with SAGE_CHECK=yes, but I guess I should... Anyway, the Sage test suite (make ptestlong) works.

I tried to verify your claim that it became faster for exponents between 4 and 8. I tested 6. First, in vanilla sage-5.0.rc0:

sage: K.<z> = GF(2^6)
sage: %time A = random_matrix(K,10000,10000)
CPU times: user 1.63 s, sys: 0.06 s, total: 1.70 s
Wall time: 1.70 s
sage: %time B = random_matrix(K,10000,10000)
CPU times: user 1.53 s, sys: 0.04 s, total: 1.58 s
Wall time: 1.58 s
sage: %time (A*B).rank()
CPU times: user 85.03 s, sys: 0.12 s, total: 85.15 s
Wall time: 85.40 s
10000

With the new spkgs in sage-5.0.beta13:

sage: K.<z> = GF(2^6)
sage: %time A = random_matrix(K,10000,10000)
CPU times: user 1.77 s, sys: 0.07 s, total: 1.84 s
Wall time: 1.85 s
sage: %time B = random_matrix(K,10000,10000)
CPU times: user 1.76 s, sys: 0.03 s, total: 1.79 s
Wall time: 1.80 s
sage: %time (A*B).rank()
CPU times: user 37.38 s, sys: 0.23 s, total: 37.61 s
Wall time: 37.74 s
10000

Now, that is faster for the "real" computation, but roughly 10% slower for random matrix creation. Is that a random result within the margin of error?

comment:26 in reply to: ↑ 25 Changed 9 years ago by SimonKing

Replying to SimonKing:

Replying to malb:

The bugfixes mainly concern the testsuite:

I didn't install the package with SAGE_CHECK=yes, but I guess I should...

I did, and the self-tests pass.

comment:27 in reply to: ↑ 25 Changed 9 years ago by malb

Replying to SimonKing:

Now, that is faster for the "real" computation, but roughly 10% slower for random matrix creation. Is that a random result within the margin of error?

I don't recall that anything changed in random matrix creation, so I'd assume it's down to margin of error.

comment:28 follow-up: Changed 9 years ago by SimonKing

I get

king@mpc622:/mnt/local/king/SAGE/stable/sage-5.0.beta13/spkg/optional/libm4rie-20120415$ hg status
M spkg-install
king@mpc622:/mnt/local/king/SAGE/stable/sage-5.0.beta13/spkg/optional/libm4rie-20120415$ hg diff
diff --git a/spkg-install b/spkg-install
--- a/spkg-install
+++ b/spkg-install
@@ -26,7 +26,7 @@
 CPPFLAGS="$INCLUDES"
 
 if [ "x$SAGE_DEBUG" = "xyes" ]; then
-   CFLAGS="-O0 $CFLAGS"
+   CFLAGS="$CFLAGS -O0"
    ENABLE_DEBUG="--enable-debug"
 else
    CFLAGS="-O2 $CFLAGS"

So, please update the package by checking in the changes!

Apart from that, self tests and make ptestlong pass, and we see some speed-up. I only tested on one platform, though. Jeroen, can you confirm that the problem you mentioned is fixed?

comment:29 Changed 9 years ago by malb

Whoops, yeah, I left those uncommitted because there was a bit of discussion whether we should have this or not, i.e., should SAGE_DEBUG overwrite the optimisation level you specify in in CFLAGS. I'm inclined that it shouldn't so I will revert this change.

comment:30 Changed 9 years ago by malb

Hi, I updated the SPKG accordingly.

comment:31 in reply to: ↑ 28 Changed 9 years ago by jdemeyer

  • Reviewers set to Simon King, Jeroen Demeyer
  • Work issues autoheader deleted

Replying to SimonKing:

Apart from that, self tests and make ptestlong pass, and we see some speed-up. I only tested on one platform, though. Jeroen, can you confirm that the problem you mentioned is fixed?

Yes, it does.

I also agree with leaving the -O0 as it is.

comment:32 Changed 9 years ago by malb

  • Description modified (diff)

comment:33 Changed 9 years ago by vbraun

  • Reviewers changed from Simon King, Jeroen Demeyer to Simon King, Jeroen Demeyer, Volker Braun
  • Status changed from needs_review to positive_review

I looked at it with #12840 and looks good to me. Lets get this boat off the ground ;-)

comment:34 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-5.1 to sage-5.2

comment:35 Changed 9 years ago by vbraun

  • Status changed from positive_review to needs_work
  • Work issues set to solaris

I tried to compile this on mark (sparc solaris) and it dies at

g++ -DHAVE_CONFIG_H -I. -I./src   -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include    -I/include   -I/include -I/include   -MT test_trsm-test_trsm.o -MD -MP -MF .deps/test_trsm-test_trsm.Tpo -c -o test_trsm-test_trsm.o `test -f 'tests/test_trsm.cc' || echo './'`tests/test_trsm.cc
mv -f .deps/test_trsm-test_trsm.Tpo .deps/test_trsm-test_trsm.Po
/bin/bash ./libtool --tag=CXX   --mode=link g++    -I/include   -I/include -I/include   -Wl,-rpath,.libs/ -L/home/vbraun/opt/mark/sage-5.1.beta3/local/lib -o test_trsm test_trsm-test_trsm.o -L/lib -lm4ri -lm4rie -lgivaro -lgmpxx -lgmp -lm -lstdc++ 
libtool: link: g++ -I/include -I/include -I/include -Wl,-rpath -Wl,.libs/ -o .libs/test_trsm test_trsm-test_trsm.o  -L/home/vbraun/opt/mark/sage-5.1.beta3/local/lib -L/lib /home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src/.libs/libm4rie.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libm4ri.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libpng12.so -lz /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgivaro.so -L/home/vbraun/opt/mark/sage-5.1.beta3/local//lib /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgmpxx.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgmp.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libstdc++.so -lm -Wl,-R -Wl,/home/vbraun/opt/mark/sage-5.1.beta3/local/lib
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make[2]: *** [test_trsm] Error 1
make[2]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src'
make: *** [check-recursive] Error 1

Only more sophisticated linkers understand -rpath, its better to use -R. Though you shouldn't have to manually set rpaths in libm4rie-20120613/src/bench/Makefile.am at all, the whole autotools/libtools machinery should do that for you.

comment:36 Changed 9 years ago by malb

  • Status changed from needs_work to needs_review

Okay, I dropped it from Makefile.am and replaced the SPKG at the same address.

(It is still used in my benchmarking code of M4RIE but that isn't built by Sage.)

comment:37 Changed 9 years ago by vbraun

Still dying on mark/skynet, though now at a different place:

/bin/bash ./libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src   -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include    -I/include  -O2 -fPIC -Wall -pedantic -g  -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c -o gf2e.lo `test -f 'src/gf2e.c' || echo './'`src/gf2e.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c src/gf2e.c  -fPIC -DPIC -o .libs/gf2e.o
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c src/gf2e.c -o gf2e.o >/dev/null 2>&1
mv -f .deps/gf2e.Tpo .deps/gf2e.Plo
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src   -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include    -I/include  -O2 -fPIC -Wall -pedantic -g  -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT mzed.lo -MD -MP -MF .deps/mzed.Tpo -c -o mzed.lo `test -f 'src/mzed.c' || echo './'`src/mzed.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT mzed.lo -MD -MP -MF .deps/mzed.Tpo -c src/mzed.c  -fPIC -DPIC -o .libs/mzed.o
In file included from src/mzed.c:23:0:
src/mzed.h:50:24: fatal error: m4rie/gf2e.h: No such file or directory
compilation terminated.
make[1]: *** [mzed.lo] Error 1
make[1]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src'
make: *** [all-recursive] Error 1
Error building libm4rie

comment:38 Changed 9 years ago by vbraun

Updated spkg builds on mark/skynet. Now doctesting...

comment:39 Changed 9 years ago by vbraun

I keep getting bus errors (aka segfaults) on mark/skynet with pickling of matrix_modn_dense_double matrices. The _pickle method uses mod_int and not celement, I'm totally confused about that. Note that on mark/skynet:

sage: cython('def f():\n    return (sizeof(double), sizeof(unsigned long))\n')
sage: f()
(8, 4)

This might not be the fault of your patch, but its hard to un-apply the spkgs.

comment:41 Changed 9 years ago by malb

This is with only M4RI/M4RIE applied, not the LinBox? update, right?

The elements in Matrix_modn_double should fit into a mod_int since they are < 223. Hence, we simply used the same pickling format as the old Matrix_modn_dense.

comment:42 Changed 9 years ago by vbraun

Yes, just with M4RI/M4RIE. The buildbot failure I linked to is even without the M4RI/M4RIE update.

comment:43 Changed 9 years ago by vbraun

From http://docs.oracle.com/cd/E19957-01/806-3568/ncg_math.html about the double bit format:

In the SPARC architecture, the higher address 32-bit word contains the least significant 32 bits of the fraction, while in the x86 architecture the lower address 32-bit word contains the least significant 32 bits of the fraction.

comment:44 follow-up: Changed 9 years ago by malb

But we're doing a cast, shouldn't that take care of it?

comment:45 in reply to: ↑ 44 Changed 9 years ago by jdemeyer

Replying to malb:

But we're doing a cast, shouldn't that take care of it?

What lines of code are you talking about? The problem might be alignment, i.e. doubles should be aligned on a multiple of 8 bytes.

comment:46 Changed 9 years ago by malb

I mean this:

http://hg.sagemath.org/sage-main/file/01e0779db321/sage/matrix/matrix_modn_dense_template.pxi#l650

But perhaps we should wait until we've run this through a gdb before we speculate which lines fail? :)

comment:47 follow-up: Changed 9 years ago by jdemeyer

What's the mod_int type and where do doubles come in?

Version 0, edited 9 years ago by jdemeyer (next)

comment:48 in reply to: ↑ 47 Changed 9 years ago by jdemeyer

What are the mod_int and celement types and where do doubles come in?

Last edited 9 years ago by jdemeyer (previous) (diff)

comment:49 Changed 9 years ago by vbraun

gdb isn't installed on mark. the only debugger is mdb and I have no idea how to use it. But the bus error is at the i=j=0 assignment (using print) in _pickle.

I thought mod_int = long int and celement = double (in matrix_modn_dense_double)

The cast to mod_int is working correctly, though.

Last edited 9 years ago by vbraun (previous) (diff)

comment:50 Changed 9 years ago by vbraun

For the record, matrix_modn_dense_template.pxi with some extra prints:

        else:
            print 'word_size != sizeof(char)', word_size, <int><char*>s
            um = <mod_int*><char *>s
            for i in range(self._nrows):
                row_self = self._matrix[i]
                row_um = &um[i*self._ncols]
                for j in range(self._ncols):
                    print i, j, row_self[j], <mod_int>row_self[j], self._ncols, self._nrows, <int>row_um
                    row_um[j] = <mod_int>row_self[j]
                    print "crash"

yields

sage: random_matrix(ZZ.quo(123456), 10,10)._pickle()
word_size != sizeof(char) 8 68071796
0 0 60348.0 60348 10 10 68071796
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/vbraun/opt/mark/sage-5.1.beta3/devel/sage-main/<ipython console> in <module>()

/home/vbraun/opt/mark/sage-5.1.beta3/local/lib/python2.7/site-packages/sage/matrix/matrix_modn_dense_double.so in sage.matrix.matrix_modn_dense_double.Matrix_modn_dense_template._pickle (sage/matrix/matrix_modn_dense_double.cpp:6537)()

RuntimeError: Bus error

comment:51 Changed 9 years ago by vbraun

Jeroen was right, its an alignment thing. The output of PyString_FromStringAndSize is 4 but not 8-byte aligned. By faking it

            um = <mod_int*>((<char *>s)+4)

I avoided the crash.

comment:52 Changed 9 years ago by malb

But it seems it's not double alignment? By the time it hits unaligned memory it's already a mod_int == long.

comment:53 Changed 9 years ago by jdemeyer

But note that wordsize == sizeof(mod_int) == 8 according to Volker's print statement.

comment:54 Changed 9 years ago by jdemeyer

The problem is that sage/ext/multi_modular.h defines

#define mod_int uint_fast64_t

So, mod_int is actually uint_fast64_t.

Last edited 9 years ago by jdemeyer (previous) (diff)

comment:55 follow-up: Changed 9 years ago by jdemeyer

The file sage/ext/multi_modular.h seems to be used by LinBox. But matrix_modn_double_* has a conflicting definition of mod_int. It is supposed to be the same or did you both use the same name for a type accidentally?

comment:56 Changed 9 years ago by jdemeyer

Note that the conflicting types might not even a problem, as Cython doesn't really care much about types. The definition

ctypedef unsigned long mod_int

mostly just makes Cython aware that mod_int is some (integer?) type, the actual type doesn't really matter as far as I know.

Last edited 9 years ago by jdemeyer (previous) (diff)

comment:57 in reply to: ↑ 55 Changed 9 years ago by SimonKing

Replying to jdemeyer:

The file sage/ext/multi_modular.h seems to be used by LinBox. But matrix_modn_double_* has a conflicting definition of mod_int. It is supposed to be the same or did you both use the same name for a type accidentally?

FWIW: I made a similar experience on Solaris with my MeatAxe wrapper (and, if I remember correctly, the same problem has shown up a while ago when trying to use Singular options in !libSingular). Namely, MeatAxe uses a function mulmat (or matmul? Doesn't matter...), but apparently a function of the same name is defined in some other spkg as well. And apparently the Solaris linker was confusing the two mulmats, even though they belong to totally different packages! In particular, MeatAxe does not link against the other package.

The simple solution was to rename MeatAxe's mulmat into _mulmat. So, renaming mod_int into something else would be worth a try.

comment:58 Changed 9 years ago by malb

Perhaps 64-bit integers need to be 8-byte aligned as well? Also, I guess

ctypedef unsigned long mod_int

should be replaced by the correct typedef, to make it less confusing. In any case, I opened a new ticket at #13151 since this is not M4RIE releated.

comment:59 Changed 9 years ago by vbraun

The cast is defined at compile-time, not at link-time. To summarize, the problem really is that malloc on Solaris only returns 32-bit aligned memory.

Simon: There is only a single flat namespace on Linux and Solaris, so if any shared library imports conflicting symbols then its just luck to get the right one.

comment:60 Changed 9 years ago by vbraun

  • Status changed from needs_review to positive_review

Other doctests pass, so lets give this a go.

comment:61 Changed 9 years ago by jdemeyer

  • Work issues solaris deleted

comment:62 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-5.2 to sage-pending

comment:63 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-pending to sage-5.3

comment:64 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-5.3 to sage-pending

comment:65 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-pending to sage-5.3

comment:66 Changed 9 years ago by jdemeyer

  • Merged in set to sage-5.3.beta0
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.