search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.3k stars 447 forks source link

update M4RI to newest upstream release #11574

Closed malb closed 12 years ago

malb commented 13 years ago

M4RI 20110601 changed the API, so we need to apply a patch as well,

cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715

Depends on #11261 Depends on #11756

CC: @strogdon @nexttime @alexanderdreyer

Component: packages: standard

Keywords: sd32

Author: Martin Albrecht

Reviewer: Simon King, Alexander Dreyer

Merged: sage-4.7.2.alpha3

Issue created by migration from https://trac.sagemath.org/ticket/11574

malb commented 13 years ago

Description changed:

--- 
+++ 
@@ -1,3 +1,6 @@
 M4RI 20110601 changed the API, so we need to apply a patch as well, 

 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
+
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110601.spkg
+* **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
malb commented 13 years ago

Dependencies: #11261

kcrisman commented 13 years ago
comment:3

I'm a little confused. The spkgs here and at #9562 are both libm4ri, and seem to be numbered backwards (the "earlier" one in the dependency is from 2011).

kcrisman commented 13 years ago
comment:4

Okay, I think I figured it out. Sorry for the noise.

kcrisman commented 13 years ago
comment:5

I don't know what I did wrong, but I still get the problem with the Symbol not found: _m4ri_swap_bits while trying to start, even after this patch. I may have done something wrong, but at any rate I can't spend more time on this now, sorry.

malb commented 13 years ago

Description changed:

--- 
+++ 
@@ -1,6 +1,7 @@
 M4RI 20110601 changed the API, so we need to apply a patch as well, 

 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
+cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715

-* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110601.spkg
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
 * **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
malb commented 13 years ago

Author: Martin Albrecht

malb commented 13 years ago
comment:7

For the record, I tried spkg + patch on t2 and doctests pass.

malb commented 13 years ago

Description changed:

--- 
+++ 
@@ -3,5 +3,5 @@
 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715

-* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
+* **Install** https://bitbucket.org/malb/m4ri/downloads/libm4ri-20110715.spkg
 * **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
malb commented 13 years ago
comment:9

applies & passes doctests with 4.7.1.rc2.

simon-king-jena commented 13 years ago

Reviewer: Simon King

simon-king-jena commented 13 years ago
comment:10

Why is the documentation for matrices over GF(2) not part of the reference manual? I think you should use the upgrade to expose the documentation to the audience.

malb commented 13 years ago
comment:11

I am not sure this documentation is much use in the reference manual since most of the interesting functions won't show up. Also, these matrices are expected to behave just as other matrices. On the other hand, there are a few - not many - special functions which are only available for GF(2). I'll take a look.

malb commented 13 years ago
comment:12

It seems that you agreed in a different ticket (#9562) that this class doesn't need to be in the reference manual? Hence, returning to needs review. Feel free to change it back, though.

simon-king-jena commented 13 years ago
comment:13

I think I can live with not including it into the references. However, currently I am getting segment faults when doctesting on mark (one of the skynet machines). I try to make sure that I properly install everything from scratch again, before reporting details.

simon-king-jena commented 13 years ago
comment:14

I did a forced new installation of the polybori spkg, then of the M4RI spkg, and I also installed the patches. I get on mark:

sage: P.<a,b,c,d,e> = PolynomialRing(GF(2), 5, order='lex')
sage: I1 = ideal([a*b + c*d + 1, a*c*e + d*e, a*b*e + c*e, b*c + c*d*e + 1])
sage: B.<a,b,c,d,e> = BooleanPolynomialRing(5, order='lex')
sage: I2 = ideal([B(f) for f in I1.gens()])
sage: I2.groebner_basis()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/simonking/SAGE/sage-4.7.1.rc1mark/devel/sage-main/<ipython console> in <module>()

/home/simonking/SAGE/sage-4.7.1.rc1mark/local/lib/python2.6/site-packages/sage/rings/polynomial/pbori.so in sage.rings.polynomial.pbori.BooleanPolynomialIdeal.groebner_basis (sage/rings/polynomial/pbori.cpp:26221)()

RuntimeError: Segmentation fault

Of course, it could be that the problem comes from the polybori spkg. That would be unfortunate, since it is already merged.

simon-king-jena commented 13 years ago
comment:15

Now, I tried to force re-installation of the original polybori spkg. However, that failed as well. I hope that it will not be needed to rebuild all of sage, which takes ages on mark.

malb commented 13 years ago
comment:16

I think the issue is that one needs to install stuff in the right order:

simon-king-jena commented 13 years ago
comment:17

Meanwhile I managed to revert to the original state, and can confirm that, with vanilla sage-4.7.1.rc2 on 32-bit solaris, the segfault above does not occur.

I will now try to do things in the order you suggested: In fact, originally I had installed polybori, then m4ri, then the m4ri patch, and then sage -b (without touching decl.pxd).

But how can the new polybori spkg be merged if apparently it depends on the new m4ri?

simon-king-jena commented 13 years ago
comment:18

The new installation order did the trick, the segfault has gone. I am now repeating the failing doctests.

simon-king-jena commented 13 years ago
comment:19

Or actually I am repeating sage -testall.

malb commented 13 years ago
comment:20

Replying to @simon-king-jena:

But how can the new polybori spkg be merged if apparently it depends on the new m4ri?

Hi, the PolyBoRi does not depend on the new M4RI. This version of M4RI breaks binary compatibility with previous M4RI, i.e. we changed how matrices look internally. Hence, for many pieces of software linking against M4RI one needs to rebuild them to make sure they are talking to the right M4RI library in the right way. That's why M4RI and the PolyBoRi is necessary: to tell PolyBoRi to use this new version. I think we need to updated PolyBoRi as well because some macro names changed and PolyBoRi 0.7.1.p4 contains the necessary code to deal with it.

simon-king-jena commented 13 years ago
comment:21

The tests took 84373.7 seconds on mark, and there were a couple of timeouts. However, there was no failure. The segfault that I reported above vanished by installing everything in the right order. On my computer, all tests pass.

Moreover, it is a prerequisite for working with M4RIE (#9562), which I think is a very important contribution - currently, matrices over GF(2e) are painfully slow in Sage.

I think it is ok that the matrices over GF(2) do not have their own section in the reference manual, since there seems that all non-underscore methods are already present for general matrices.

Hence, it is a positive review.

malb commented 13 years ago
comment:22

Woot!

williamstein commented 13 years ago
comment:23

I'm upping the priority, since this fixes a serious mathematical bug reported on sage-support.

jdemeyer commented 13 years ago
comment:24

The directory m4ri should be added to .hgignore

malb commented 13 years ago
comment:25

the updated SPKG fixes this issue.

malb commented 13 years ago

Description changed:

--- 
+++ 
@@ -3,5 +3,5 @@
 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110601
 cf. https://bitbucket.org/malb/m4ri/wiki/M4RI-20110715

-* **Install** https://bitbucket.org/malb/m4ri/downloads/libm4ri-20110715.spkg
+* **Install** http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20110715.spkg
 * **Apply** [attachment: m4ri_20110601.patch](https://github.com/sagemath/sage-prod/files/10653267/m4ri_20110601.patch.gz)
jdemeyer commented 13 years ago

Merged: sage-4.7.2.alpha2

jdemeyer commented 13 years ago

Changed merged from sage-4.7.2.alpha2 to none

jdemeyer commented 13 years ago
comment:27

On some 32-bit Linux systems (for example, the buildbot machine cicero), this causes polybori to fail to install:

g++ -o groebner/src/randomset.o -c -O3 -Wno-long-long -Wreturn-type -g -fPIC -ftemplate-depth-100 -O3 -Wno-long-long -Wreturn-type -g -fPIC -DNDEBUG -DHAVE_GD -DHAVE_TR1_UNORDERED_MAP -DPACKED -DHAVE_M4RI -DHAVE_GD -DHAVE_IEEE_754 -DBSD -I/home/jdemeyer/sage-4.7.2.alpha1/local/include -I/home/jdemeyer/sage-4.7.2.alpha1/local/include/python2.6 -Ipolybori/include -ICudd/obj -ICudd/util -ICudd/cudd -ICudd/mtr -ICudd/st -ICudd/epd groebner/src/randomset.cc
In file included from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:42,
                 from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31,
                 from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
                 from groebner/src/nf.h:15,
                 from groebner/src/randomset.cc:11:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
In file included from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31,
                 from /home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
                 from groebner/src/nf.h:15,
                 from groebner/src/randomset.cc:11:
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_row_add_offset(mzd_t*, rci_t, rci_t, rci_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: '__src' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:741: error: expected ';' before 'src'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: '__dst' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:742: error: expected ';' before 'dst'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:743: error: expected primary-expression before 'const'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:743: error: expected ';' before 'const'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:746: error: expected ';' before 'xmm1'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:747: error: 'xmm1' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:749: error: 'eof' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_combine_even_in_place(mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: 'a128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1190: error: expected ';' before 'a'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: 'b128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1191: error: expected ';' before 'b'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1192: error: expected initializer before '*' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1195: error: '_mm_xor_si128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1198: error: 'eof' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h: In function 'void mzd_combine_even(mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t, const mzd_t*, rci_t, wi_t)':
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: '__m128i' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: 'a128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1274: error: expected ';' before 'a'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: 'b128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1275: error: expected ';' before 'b'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: 'c128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: expected primary-expression before ')' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1276: error: expected ';' before 'c'
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1277: error: expected initializer before '*' token
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1280: error: '_mm_xor_si128' was not declared in this scope
/home/jdemeyer/sage-4.7.2.alpha1/local/include/m4ri/packedmatrix.h:1284: error: 'eof' was not declared in this scope
scons: *** [groebner/src/randomset.o] Error 1
scons: building terminated because of errors.
malb commented 13 years ago
comment:30

Can you allow me to read your build on cicero (my username is malb). I don't have a copy of Sage on cicero and it would save me some time.

williamstein commented 13 years ago

Changed keywords from none to sd32

jdemeyer commented 13 years ago
comment:32

Replying to @malb:

Can you allow me to read your build on cicero (my username is malb). I don't have a copy of Sage on cicero and it would save me some time.

It's in /home/buildbot/build/sage/cicero-1/cicero_full/build/sage-4.7.2.alpha2 (should be accessible through NFS on any Skynet machine).

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:33

Replying to @jdemeyer:

On some 32-bit Linux systems (for example, the buildbot machine cicero), this causes polybori to fail to install:

[...] Here on my system the old m4ri/config.h stays when the new libm4ri spkg is installed. Maybe something around polybori picks the outdated file?

Regards, Alexander

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:34

Replying to @alexanderdreyer:

Here on my system the old m4ri/config.h stays when the new libm4ri spkg is installed. Maybe something around polybori picks the outdated file?

As Jeroen pointed out this is not related. Unfortunately I cannot reproduce this behaviour. Is there some machine on which this occurs, which I may be granted access to?

malb commented 13 years ago
comment:35

Replying to @alexanderdreyer:

As Jeroen pointed out this is not related. Unfortunately I cannot reproduce this behaviour. Is there some machine on which this occurs, which I may be granted access to?

The only machine which I know of is 'cicero' on skynet. We could try to get you an account there but it would take a while I guess. Right now, I cannot even log into the machine.

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:36

Replying to @malb:

The only machine which I know of is 'cicero' on skynet. We could try to get you an account there but it would take a while I guess. Right now, I cannot even log into the machine.

This would be nice. I'm about to prepare a qemu image for Gentoo x86. But that will last for some time since I have to compile everything from scratch (It's Gentoo.)

kiwifb commented 13 years ago
comment:37

I think thing go south from there

/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"

I had a x86 box without sse2 but it is now collecting dust without an OS installed. I will take a look on the closest thing I can get. Actually Steve Trogdon could have a box where this could be tested, I am copying him.

strogdon commented 13 years ago
comment:38

Replying to @kiwifb:

I think thing go south from there

/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"

I had a x86 box without sse2 but it is now collecting dust without an OS installed. I will take a look on the closest thing I can get. Actually Steve Trogdon could have a box where this could be tested, I am copying him.

I get the same failure as comment:33

/storage/strogdon/gentoo/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled"
In file included from /storage/sage-python2.6/sage-4.7.2.alpha1/local/include/m4ri/permutation.h:31:0,
                 from /storage/sage-python2.6/sage-4.7.2.alpha1/local/include/m4ri/m4ri.h:50,
                 from groebner/src/nf.h:15,
                 from groebner/src/randomset.cc:11:

...

scons: *** [groebner/src/randomset.o] Error 1
scons: building terminated because of errors.
Error building PolyBoRi.
malb commented 13 years ago
comment:39

M4RI should test for SSE2 and only include that header if it is present. Since it worked so far, I assume it still does that. However, we recently switched from HAVE_SSE2 to __M4RI_HAVE_SSE2 and this might be a change that PolyBoRi didn't pick up? However, it shouldn't be PolyBoRi's responsibility to check for SSE2 and hence something goes wrong when including m4ri.h.

malb commented 13 years ago
comment:40

For some reason m4ri_config.h on cicero has

#define __M4RI_HAVE_SSE2                1

which is totally wrong! I'll investigate.

malb commented 13 years ago
comment:41

More data on cicero:

cat /proc/cpuinfo reports SSE2

flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts

but /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:32:3 complains. I assume this is because neither PolyBoRi nor Sage pass -msse2 when linking against M4RI but -msse2 defines __SSE2__ which is required by emmintrin.h. But I don't understand yet why the previous version works.

malb commented 13 years ago
comment:42

I can confirm that passing -msse2 fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:43

Replying to @malb:

I can confirm that passing -msse2 fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?

For scons-bases builds (PolyBoRi as well as Sage) I should be able to provide a suitable code snipplet which checks whether __M4RI_HAVE_SSE2 is defined in m4ri/m4ri_config.h.

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:44

We have added some configuration for this here: https://bitbucket.org/brickenstein/polybori/changeset/e5ecbbe5a904 I'll backport this to 0.7.1 and bundle a new spkg asap.

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:45

PS: I'm also checking things like sse3 which m4ri might or might not use in the future.

malb commented 13 years ago
comment:46

Hi Alexander,

so your plan is to parse for __M4RI_HAVE_SSE2=1 and then pass -msse2 manually? The only caveat I could see with that approach is that it limits us to use !GCC. For Sage this isn't really a problem. M4RI supports more compilers. How's that for PolyBoRi?

If we want to support more compilers I was thinking about dumping the CFLAGS to disk in M4RI which third party tools then can re-use. I was thinking of using the pkg-config.rc file which one can then either use via pkg-config or parse oneself.

PS: Sage's main build scripts are not !Scons based, but I can certainly take care of those.

d46d2cb1-860f-484d-8329-8ebfc9f5d004 commented 13 years ago
comment:48

Replying to @malb:

The only caveat I could see with that approach is that it limits us to use !GCC. For Sage this isn't really a problem. M4RI supports more compilers. How's that for PolyBoRi?

We support only gcc yet. In the case that we would add additional ones we'll add a mapping of non-default compiler options anyway. (e.g. -msse2 -> -xarch-sse2 for sun studio). But if you could export the original parameters, this would of course be better.

If we want to support more compilers I was thinking about dumping the CFLAGS to disk in M4RI which third party tools then can re-use. I was thinking of using the pkg-config.rc file which one can then either use via pkg-config or parse oneself.

I would prefer if you could add a macro defining the options as a string literal to m4ri_config.h. But if you need to setup the rc file anyway, you do not have to duplicate work.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:49

Replying to @malb:

I can confirm that passing -msse2 fixes the issue. I guess I'll have to find a way to save the flags (to disc?) such that third parties (PolyBoRi, Sage) can re-use them? Any suggestions on how to do that?

Take a look at GMP's / MPIR's gmp.h and the various libs (like e.g. MPFR) that use it:

$ egrep -B1 "__GMP_(CC|CFLAGS)" /usr/include/gmp.h
/* Define CC and CFLAGS which were used to build this version of GMP */
#define __GMP_CC "gcc -std=gnu99"
#define __GMP_CFLAGS "-march=native -g -O3"

I for example use (slightly OT):

# We eventually use / add these settings (or parts of them) to "our" CFLAGS,
# e.g. "-march=..." or "-mcpu=..." and "-mtune=..." to let gcc generate better,
# processor-specific code, since ECM doesn't use them if we set our own:
gmp_cc_pat='/^[     ]*#[    ]*define[   ]\+__GMP_CC[    ]\+/s/.*"\([^"]*\)"/\1/p'
gmp_cflags_pat='/^[     ]*#[    ]*define[   ]\+__GMP_CFLAGS[    ]\+/s/.*"\([^"]*\)"/\1/p'

gmp_cc=`sed -n -e "$gmp_cc_pat" "$SAGE_LOCAL"/include/gmp.h`
gmp_cflags=`sed -n -e "$gmp_cflags_pat" "$SAGE_LOCAL"/include/gmp.h`

system_gmp_h=""
for incdir in /usr/include /usr/local/include; do
    if [ -f $incdir/gmp.h ]; then
        system_gmp_h=$incdir/gmp.h
    fi
done
if [ -n "$system_gmp_h" ]; then
    system_gmp_cc=`sed -n -e "$gmp_cc_pat" $system_gmp_h`
    system_gmp_cflags=`sed -n -e "$gmp_cflags_pat" $system_gmp_h`
fi

...

    else
        # 'native' not supported, see if GMP / MPIR provides us some CPU type:
        for opt in $gmp_cflags; do
            case $opt in
                -march=*|-mcpu=*|-mtune*)
                    echo "Found CPU parameter in gmp.h: $opt"
                    cpu_params="$cpu_params $opt"
                    ;;
                 # perhaps add other options, too (e.g. for different compilers)
                 *) other_gmp_cflags="$other_gmp_cflags $opt"
            esac
        done
    fi
    # Only add them if CFLAGS do not already contain similar:
    if [ -n "$cpu_params" ] &&
        ! (echo "$CFLAGS" | egrep -- '-march=|-mcpu=|-mtune=' >/dev/null);
    then
        echo "Using additional host-specific CFLAGS: $cpu_params"
        CFLAGS="$cpu_params $CFLAGS"
    fi
    if [ -n "$other_gmp_cflags" ]; then
        echo "Not using other CFLAGS provided by gmp.h: $other_gmp_cflags"
    fi
...

Putting at least the necessary flags into libm4ri.pc is of course another, non-exclusive option, and even on systems that lack pkg-config, you could use the .pc file by adding a few lines of shell, Python or whatever code.

You can also test whether adding -msse2 (if using SSE2 is desired) is necessary at all, or supported (for simplicity, here gcc-specific):

# Test whether '-msse2' is supported at all:
if $CC -msse2 -c -x c /dev/null -o /dev/null &>/dev/null; then
    # Ok, supported. Do we need it?
    # [Should perhaps check whether __SSE2__ is really non-zero.]
    if ($CC -E -dM -x c /dev/null | grep -w __SSE2__) &>/dev/null; then
        # Fine, we don't need to pass any options to enable SSE2.
        required_cflag=""
    else
        required_cflag="-msse2"
    fi
    # Check whether the flag conflicts with others, perhaps specified by the user:
    if $CC $CFLAGS $required_cflag -c -x c /dev/null -o /dev/null &>/dev/null; then
        # Ok, compatible and sufficient.
    else
        # Conflicting flags, issue error message or try something else...
    fi
else
    # Not supported, perhaps disable use of SSE2.
fi

(The same tests can easily be performed from Python as well, e.g. in [Sage's] setup.py or module_list.py. You could also steal macros from autotools.)