Testing new MPIR spkg on old Mac OSX

[Jean-Pierre Flori]

Dear all,

While updating MPIR in #13137, we remarked the old fix for compilation on OSX 10.4 (and maybe 10.5) running in 32 bit mode on 64 bit Intel hardware was not maintained properly and does not do what it was supposed to do anymore.
This is not so bad because it seems to indicate that the fix is actually not needed anymore (or someone would have complained at some point), not sure why, maybe now MPIR uses YASM to compile the problematic files on OSX (which were renamed but whose content did not change).

Could someone test the updated spkg on the setup mentioned above to check our assumption is correct?
Or does nobody use such a setup anymore?

Best,
JP

[Dima Pasechnik]

On 2012-11-30, Jean-Pierre Flori <jpf...@gmail.com> wrote:
> ------=_Part_1212_10818395.1354274078891
> Content-Type: text/plain; charset=ISO-8859-1

I imagine that everyone on Intel OSX 10.4/5 upgraded to 10.6 ages ago.
I still have a G4 PPC OSX 10.5 working system lying around.
Not sure if it makes sense to test what you ask for on it, though.

Dima

>
> Best,
> JP
>

[Jean-Pierre Flori]

On Friday, November 30, 2012 3:50:43 PM UTC+1, Dima Pasechnik wrote:

On 2012-11-30, Jean-Pierre Flori <jpf...@gmail.com> wrote:
> ------=_Part_1212_10818395.1354274078891
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear all,
>
> While updating MPIR in #13137, we remarked the old fix for compilation on
> OSX 10.4 (and maybe 10.5) running in 32 bit mode on 64 bit Intel hardware
> was not maintained properly and does not do what it was supposed to do
> anymore.
> This is not so bad because it seems to indicate that the fix is actually
> not needed anymore (or someone would have complained at some point), not
> sure why, maybe now MPIR uses YASM to compile the problematic files on OSX
> (which were renamed but whose content did not change).
>
> Could someone test the updated spkg on the setup mentioned above to check
> our assumption is correct?
> Or does nobody use such a setup anymore?
I imagine that everyone on Intel OSX 10.4/5 upgraded to 10.6 ages ago.

Quite possible.
As I said before, this is supported by the fact that nobody complained for a couple of years whereas MPIR was updated inbetween and the fix was dysfunctional.

I still have a G4 PPC OSX 10.5 working system lying around.
Not sure if it makes sense to test what you ask for on it, though.

I don't think so.
From what I've read the problem was specific to intel 64 bits processors.
But you could try anyway that would not hurt!

Cheers,
JP

[Greg McWhirter]

Unfortunately (for me at least) it is still broken as of this morning. I was unable to compile 4.5.1 or upgrade from 5.0 as a result on 10.5. hat information would be useful for potentially pursuing a fix?

- Greg McWhirter

[Jean-Pierre Flori]

On Friday, November 30, 2012 10:55:12 PM UTC+1, Greg McWhirter wrote:

Unfortunately (for me at least) it is still broken as of this morning. I was unable to compile 4.5.1 or upgrade from 5.0 as a result on 10.5. hat information would be useful for potentially pursuing a fix?

- Greg McWhirter

I guess you mean with the official Sage tarball, so with the old MPIR 2.4.x spkg.

That's not so suprising in fact.
If this is with the MPIR 2.6.0 spkg that more surprising.
Could you post (the end of) the MPIR build log (in spkg/log).
It should contain something complaining about @GOT and garbage.

If this is indeed the case, I could try rebasing the old patches which basically must try to remove all ASM file using the GOT thing which Apple's as does not understand.

Best,
JP

[Greg McWhirter]

Ah, yes. It was with the older 2.4 (2.4.0.p6). I should have confirmed that it was the same one before replying. Sorry for the potential confusion there.

At any rate, the last bits of the log are appended below (and if you need more, let me know). I'd be happy to help test future changes as well, since this machine will likely not be upgraded past 10.5.8 anytime soon.

- Greg

Log snip:

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo rshift | sed 's/_$//'` -I. -I..  `test -f 'rshift.asm' || echo './'`rshift.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. rshift.asm  -fno-common -DPIC -o .libs/rshift.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_rshift -DPIC rshift.asm >tmp-rshift.s

 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. tmp-rshift.s -fno-common -DPIC -o .libs/rshift.o

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I..  `test -f 'divexact_1.asm' || echo './'`divexact_1.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm  -fno-common -DPIC -o .libs/divexact_1.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm >tmp-divexact_1.s

 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o

tmp-divexact_1.s:120:junk `@GOT' after expression

make[5]: *** [divexact_1.lo] Error 1

make[4]: *** [all-recursive] Error 1

make[3]: *** [all] Error 2

Error building MPIR.

real 1m43.928s

user 0m48.971s

sys 0m44.170s

************************************************************************

Error installing package mpir-2.4.0.p6

************************************************************************

Please email sage-devel (http://groups.google.com/group/sage-devel)

explaining the problem and including the relevant part of the log file

  /Users/gmcwhirt/sage-5.4.1/spkg/logs/mpir-2.4.0.p6.log

Describe your computer, operating system, etc.

If you want to try to fix the problem yourself, *don't* just cd to

/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.4.0.p6 and type 'make' or whatever is appropriate.

Instead, the following commands setup all environment variables

correctly and load a subshell for you to debug the error:

  (cd '/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.4.0.p6' && '/Users/gmcwhirt/sage-5.4.1/sage' -sh)

When you are done debugging, you can type "exit" to leave the subshell.

************************************************************************

[Jean-Pierre Flori]

On Saturday, December 1, 2012 1:57:38 AM UTC+1, Greg McWhirter wrote:

Ah, yes. It was with the older 2.4 (2.4.0.p6). I should have confirmed that it was the same one before replying. Sorry for the potential confusion there.

At any rate, the last bits of the log are appended below (and if you need more, let me know). I'd be happy to help test future changes as well, since this machine will likely not be upgraded past 10.5.8 anytime soon.

- Greg

Log snip:

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo rshift | sed 's/_$//'` -I. -I..  `test -f 'rshift.asm' || echo './'`rshift.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. rshift.asm  -fno-common -DPIC -o .libs/rshift.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_rshift -DPIC rshift.asm >tmp-rshift.s

 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. tmp-rshift.s -fno-common -DPIC -o .libs/rshift.o

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I..  `test -f 'divexact_1.asm' || echo './'`divexact_1.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm  -fno-common -DPIC -o .libs/divexact_1.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm >tmp-divexact_1.s

 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o

tmp-divexact_1.s:120:junk `@GOT' after expression

make[5]: *** [divexact_1.lo] Error 1

make[4]: *** [all-recursive] Error 1

make[3]: *** [all] Error 2

Error building MPIR.

Thanx that's indeed the "old" error.
I guess that just nobody actually tried to build (not so) recent releases of Sage recently.

Could you try the new spkg? It should give similar results, but who knows...
Just download it from trac ticket #13137 and caal "sage -i <path to new spkg>.

[Greg McWhirter]

It does error out similarly. I tried it both on a clean source download of sage 5.4.1 (forced to use the OS X gcc 4.2 instead of the 4.0.1) and a working binary download of sage 5.0 (using sage's gcc 4.6.3). Log snips are at the end.

- Greg

Snip from 5.0:

/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo subadd_n | sed 's/_$//'`    -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7  -g  -c -o subadd_n.lo subadd_n.c

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_subadd_n -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7 -g -c subadd_n.c  -fno-common -DPIC -o .libs/subadd_n.o

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_subadd_n -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7 -g -c subadd_n.c -o subadd_n.o >/dev/null 2>&1

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I..  `test -f 'divexact_1.asm' || echo './'`divexact_1.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm  -fno-common -DPIC -o .libs/divexact_1.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm >tmp-divexact_1.s

 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=corei7 -march=corei7 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o

tmp-divexact_1.s:119:junk `@GOT' after expression

make[2]: *** [divexact_1.lo] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

Error building MPIR.

real 2m34.576s

user 1m8.157s

sys 1m20.787s

************************************************************************

Error installing package mpir-2.6.0.p0

************************************************************************

Please email sage-devel (http://groups.google.com/group/sage-devel)

explaining the problem and including the relevant part of the log file

  /Users/gmcwhirt/sage-5.0/spkg/logs/mpir-2.6.0.p0.log

Describe your computer, operating system, etc.

If you want to try to fix the problem yourself, *don't* just cd to

/Users/gmcwhirt/sage-5.0/spkg/build/mpir-2.6.0.p0 and type 'make' or whatever is appropriate.

Instead, the following commands setup all environment variables

correctly and load a subshell for you to debug the error:

  (cd '/Users/gmcwhirt/sage-5.0/spkg/build/mpir-2.6.0.p0' && '/Users/gmcwhirt/sage-5.0/sage' -sh)

When you are done debugging, you can type "exit" to leave the subshell.

************************************************************************

Snip from 5.4.1:

libtool: compile:  /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_subadd_n -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -c subadd_n.c -o subadd_n.o >/dev/null 2>&1

/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2  -g  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I..  `test -f 'divexact_1.asm' || echo './'`divexact_1.asm

libtool: compile:  ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm  -fno-common -DPIC -o .libs/divexact_1.o

m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm >tmp-divexact_1.s

 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o

tmp-divexact_1.s:119:junk `@GOT' after expression

make[2]: *** [divexact_1.lo] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

Error building MPIR.

real 2m6.551s

user 1m0.507s

sys 0m58.303s

************************************************************************

Error installing package mpir-2.6.0.p0

************************************************************************

Please email sage-devel (http://groups.google.com/group/sage-devel)

explaining the problem and including the relevant part of the log file

  /Users/gmcwhirt/sage-5.4.1/spkg/logs/mpir-2.6.0.p0.log

Describe your computer, operating system, etc.

If you want to try to fix the problem yourself, *don't* just cd to

/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.6.0.p0 and type 'make' or whatever is appropriate.

Instead, the following commands setup all environment variables

correctly and load a subshell for you to debug the error:

  (cd '/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.6.0.p0' && '/Users/gmcwhirt/sage-5.4.1/sage' -sh)

When you are done debugging, you can type "exit" to leave the subshell.

************************************************************************

[Dima Pasechnik]

On 2012-12-01, Greg McWhirter <gsmcw...@gmail.com> wrote:
> ------=_Part_1340_24540346.1354327647430
> Content-Type: text/plain; charset=ISO-8859-1

>
> It does error out similarly. I tried it both on a clean source download of
> sage 5.4.1 (forced to use the OS X gcc 4.2 instead of the 4.0.1) and a
> working binary download of sage 5.0 (using sage's gcc 4.6.3). Log snips are
> at the end.
>
> - Greg
>
> Snip from 5.0:

is your Mac "old"? The libtool thinks it has the i7 processor!

[Greg McWhirter]

It is a few years old. I don't know if that qualifies it as "old" or not. It has dual quad-core Intel Xeons in it I believe. The i7 may be an artifact of what the 5.0 binary was built on. The 5.4.1 source attempt thinks the processor is core2 to the best of my ability reading the logs.

- Greg

[Dima Pasechnik]

On 2012-12-01, Greg McWhirter <gsmcw...@gmail.com> wrote:

> ------=_Part_1437_25379457.1354339928090
> Content-Type: text/plain; charset=ISO-8859-1

>
> It is a few years old. I don't know if that qualifies it as "old" or not.
> It has dual quad-core Intel Xeons in it I believe.

what does Apple's "about this mac" tell you (see
http://ask.sagemath.org/question/2033/installation-problem-on-mac-osx?answer=2929#2929)

> The i7 may be an
> artifact of what the 5.0 binary was built on.

i7 has instructions which don't work on Xeons, IMHO.
This might explain the assembler errors you get.

> The 5.4.1 source attempt
> thinks the processor is core2 to the best of my ability reading the logs.
>
> - Greg
>
> On Friday, November 30, 2012 8:32:34 PM UTC-8, Dima Pasechnik wrote:
>>

[Greg McWhirter]

This is the result from the Terminal equivalent (system_profiler -detailLevel full SPSoftwareDataType SPHardwareDataType) since I am not physically at the computer, nor will I be again until Monday. If there is data missing that is expected, I can attempt to retrieve it specifically.

- Greg

Software:

    System Software Overview:

      System Version: Mac OS X 10.5.8 (9L31a)

      Kernel Version: Darwin 9.8.0

      Boot Volume: Macintosh HD

      Boot Mode: Normal

      Computer Name: xxxxx

      User Name: xxxxxxxxx

      Time since boot: 1 day12:02

Hardware:

    Hardware Overview:

      Model Name: Mac Pro

      Model Identifier: MacPro4,1

      Processor Name: Quad-Core Intel Xeon

      Processor Speed: 2.26 GHz

      Number Of Processors: 2

      Total Number Of Cores: 8

      L2 Cache (per core): 256 KB

      L3 Cache (per processor): 8 MB

      Memory: 12 GB

      Processor Interconnect Speed: 5.86 GT/s

      Boot ROM Version: MP41.0081.B07

      SMC Version (system): 1.39f5

      SMC Version (processor tray): 1.39f5

      Serial Number (system): xxxxxxxxxxxx

      Serial Number (processor tray): xxxxxxxxxxx

      Hardware UUID: xxxxxxxxxxxx

[Jean-Pierre Flori]

Thanks for the data.
I'll provide an updated spkg tomorrow and give a link here.

[Jean-Pierre Flori]

Updated spkg at http://boxen.math.washington.edu/home/jpflori/mpir-2.6.0.p0.spkg removing the files again.

Could you try it again? Hopefully this one should be ok.

[Jean-Pierre Flori]

On Monday, December 3, 2012 11:48:26 AM UTC+1, Jean-Pierre Flori wrote:

Updated spkg at http://boxen.math.washington.edu/home/jpflori/mpir-2.6.0.p0.spkg removing the files again.

Could you try it again? Hopefully this one should be ok.

According to upstream (even from this olg message
https://groups.google.com/forum/?fromgroups=#!msg/mpir-devel/iSzn88nJO58/4efX1gWB5kIJ
)
this should be fixed without hacks.

Could you provide us the full log (on the 5.4.1 from source install which looks saner than the other one, but having both should not hurt)?

Best,
JP

[leif]

Jean-Pierre Flori wrote:

Could you provide us the full log (on the 5.4.1 from source install which looks saner than the other one, but having both should not hurt.

According to what Bill said on mpir-devel, the most interesting thing is probably the MPN_PATH chosen by MPIR's 'configure'. 

You could try

$ grep -A6 '^using ABI' spkg/logs/mpir-*.log 

(The value of MPN_PATH should be on the last, i.e., 7th line -- if your 'grep' supports the context options...)

-leif

[Jean-Pierre Flori]

Running ./config.guess from MPIR directory would be nice as well.

[Greg McWhirter]

Running "sage -i ..." on the new spkg still fails for me. The log files I have put in a dropbox so it doesn't spam the lists with them. The links are below. I have also included dumps of the requested grep command. These are for 5.4.1 source, both with the apple gcc 4.2 and 4.0.1.

The result of ./config.guess is "nehalem-apple-darwin9.8.0" after doing (cd '/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.6.0.p0' && '/Users/gmcwhirt/sage-5.4.1/sage' -sh).

To be clear, this is against a sage 5.4.1 source download, not an actual build, in case that matters (I can't successfully "make" 5.4.1 due to this mpir issue in the 2.4 version that sage is currently shipping).

- Greg

Dropbox Links for the logs and greps:

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/mpir-log-5.4.1_gcc-4.0.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/mpir-grep-5.4.1_gcc-4.0.txt

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/mpir-log-5.4.1_gcc-4.2.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/mpir-grep-5.4.1_gcc-4.2.txt

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:28:02 PM UTC+1, Greg McWhirter wrote:

Running "sage -i ..." on the new spkg still fails for me. The log files I have put in a dropbox so it doesn't spam the lists with them. The links are below. I have also included dumps of the requested grep command. These are for 5.4.1 source, both with the apple gcc 4.2 and 4.0.1.

The result of ./config.guess is "nehalem-apple-darwin9.8.0" after doing (cd '/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.6.0.p0' && '/Users/gmcwhirt/sage-5.4.1/sage' -sh).

Ok that's not really taken into account by MPIR.
Could you go into the MPIR build dir (or untar the spkg), modify the file configure.in around line 1123 to add the above nehalem-... to the list of cases under the 32 bit apple darwin comment, then run autoreconf -i, then then issuing make again?
From or outside a sage shell should not really matter, as mpir does not have dependencies only sage should provide on your system.

If that's complicated, I'll issue a new spkg.

To be clear, this is against a sage 5.4.1 source download, not an actual build, in case that matters (I can't successfully "make" 5.4.1 due to this mpir issue in the 2.4 version that sage is currently shipping).

That's clear enough! thanks again for your help.

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:51:53 PM UTC+1, Jean-Pierre Flori wrote:

On Monday, December 3, 2012 5:28:02 PM UTC+1, Greg McWhirter wrote:

Running "sage -i ..." on the new spkg still fails for me. The log files I have put in a dropbox so it doesn't spam the lists with them. The links are below. I have also included dumps of the requested grep command. These are for 5.4.1 source, both with the apple gcc 4.2 and 4.0.1.

The result of ./config.guess is "nehalem-apple-darwin9.8.0" after doing (cd '/Users/gmcwhirt/sage-5.4.1/spkg/build/mpir-2.6.0.p0' && '/Users/gmcwhirt/sage-5.4.1/sage' -sh).

Ok that's not really taken into account by MPIR.
Could you go into the MPIR build dir (or untar the spkg), modify the file configure.in around line 1123 to add the above nehalem-... to the list of cases under the 32 bit apple darwin comment, then run autoreconf -i, then then issuing make again?
From or outside a sage shell should not really matter, as mpir does not have dependencies only sage should provide on your system.

If that's complicated, I'll issue a new spkg.

One is available at http://boxen.math.washington.edu/home/jpflori/mpir-2.6.0.p1.spkg
The spkg itself is dirty, its for testing only.

[Greg McWhirter]

I tried to patch it, but autoreconf failed (too old by default on 10.5.8 it seems):

$ autoreconf -i

configure.in:32: error: Autoconf version 2.68 or higher is required

configure.in:32: the top level

autom4te: /usr/bin/gm4 failed with exit status: 63

aclocal: autom4te failed with exit status: 63

autoreconf: aclocal failed with exit status: 63

$ autoreconf -V

autoreconf (GNU Autoconf) 2.61

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software.  You may redistribute copies of it under the terms of

the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.

There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

I tried grabbing updated autoconf and automake from Homebrew and manually linking them to /usr/local so they are used by default, but then I ran into issues with libtool when running "make". In the install note from trying to grab libtool from homebrew, it said something about needing to add my own build variables, and I wasn't sure where to do that. It also seems that having to rely on things from homebrew is not particularly helpful for testing default builds, so I reverted all the symlinks back to the OS X defaults.

I also tried grabbing the .p1 spkg to try, but got a 404 from the server.

- Greg

[Jean-Pierre Flori]

On Monday, December 3, 2012 6:42:22 PM UTC+1, Greg McWhirter wrote:

I tried to patch it, but autoreconf failed (too old by default on 10.5.8 it seems):

$ autoreconf -i

configure.in:32: error: Autoconf version 2.68 or higher is required

configure.in:32: the top level

autom4te: /usr/bin/gm4 failed with exit status: 63

aclocal: autom4te failed with exit status: 63

autoreconf: aclocal failed with exit status: 63

$ autoreconf -V

autoreconf (GNU Autoconf) 2.61

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software.  You may redistribute copies of it under the terms of

the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.

There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

I tried grabbing updated autoconf and automake from Homebrew and manually linking them to /usr/local so they are used by default, but then I ran into issues with libtool when running "make". In the install note from trying to grab libtool from homebrew, it said something about needing to add my own build variables, and I wasn't sure where to do that. It also seems that having to rely on things from homebrew is not particularly helpful for testing default builds, so I reverted all the symlinks back to the OS X defaults.

I also tried grabbing the .p1 spkg to try, but got a 404 from the server.

Oops, I launch scp but forgot to feed it with my password.
It should be ok now.

[Greg McWhirter]

I grabbed the .p1 spkg and did:

$ tar xf mpir-2.6.0.p1.spkg

$ cd mpir-2.6.0.p1/src

$ ./configure

$ make

and got the same error (about @GOT). However, now running ./config.guess in that directory results in "i386-apple-darwin9.8.0" instead of the nehalem, and I still cant run autoreconf in that directory (same reason -- too old).

- Greg

[Jean-Pierre Flori]

On Monday, December 3, 2012 6:57:28 PM UTC+1, Greg McWhirter wrote:

I grabbed the .p1 spkg and did:

$ tar xf mpir-2.6.0.p1.spkg

$ cd mpir-2.6.0.p1/src

$ ./configure

$ make

and got the same error (about @GOT). However, now running ./config.guess in that directory results in "i386-apple-darwin9.8.0" instead of the nehalem, and I still cant run autoreconf in that directory (same reason -- too old).

Ok the discrepancy of config.guess must be because I used a different version of autotools.
And as the result is now different, it is not catched as well...
I'm updating the spkg with *-apple-darwin* to catch everything.

[Jean-Pierre Flori]

On Monday, December 3, 2012 7:38:59 PM UTC+1, Jean-Pierre Flori wrote:

On Monday, December 3, 2012 6:57:28 PM UTC+1, Greg McWhirter wrote:

I grabbed the .p1 spkg and did:

$ tar xf mpir-2.6.0.p1.spkg

$ cd mpir-2.6.0.p1/src

$ ./configure

$ make

and got the same error (about @GOT). However, now running ./config.guess in that directory results in "i386-apple-darwin9.8.0" instead of the nehalem, and I still cant run autoreconf in that directory (same reason -- too old).

Ok the discrepancy of config.guess must be because I used a different version of autotools.
And as the result is now different, it is not catched as well...
I'm updating the spkg with *-apple-darwin* to catch everything.

Could you try now?
I've patched the configure.in and configure directly (so touching configure.in was useless, but I discovered afterwards that autotools on boxen are too old).

[leif]

On Monday, December 3, 2012 6:57:28 PM UTC+1, Greg McWhirter wrote:

I grabbed the .p1 spkg and did:

$ tar xf mpir-2.6.0.p1.spkg

$ cd mpir-2.6.0.p1/src

$ ./configure

$ make

and got the same error (about @GOT). However, now running ./config.guess in that directory results in "i386-apple-darwin9.8.0" instead of the nehalem, and I still cant run autoreconf in that directory (same reason -- too old).

You probably have to explicitly configure with ABI=32.  (Sage's spkg-install does this.)

The i386 thing smells like JP autoreconfed badly... ;-)

-leif

[Greg McWhirter]

Regrabbed the .p1 spkg and did:

export ABI=32

tar xf mpir-2.6.0.p1.spkg

cd mpir-2.6.0.p1/src

./config.guess #=> back to nehalem now

./configure

make

The result was a successful build (at least no errors). This was with apple's gcc-4.2 (manually set). Trying now with gcc 4.0.1 to make sure it works there too.

- Greg

[Jean-Pierre Flori]

On Monday, December 3, 2012 7:52:42 PM UTC+1, Greg McWhirter wrote:

Regrabbed the .p1 spkg and did:

export ABI=32

tar xf mpir-2.6.0.p1.spkg

cd mpir-2.6.0.p1/src

./config.guess #=> back to nehalem now

That's normal, as I began with mpir-2.6.0.p0, modified configure.in, but autoreconf failed, and then modified configure by hand.

./configure

make

The result was a successful build (at least no errors). This was with apple's gcc-4.2 (manually set). Trying now with gcc 4.0.1 to make sure it works there too.

Great news!!!
Could you post the logs as before?
I guess that x86 is not in MPN_PATH anymore, or I'll give up on uderstanding that one.

[Greg McWhirter]

It built successfully using gcc 4.0.1 as well. Is there any way to check the functionality of the builds easily?

- Greg

[Jean-Pierre Flori]

On Monday, December 3, 2012 7:55:56 PM UTC+1, Greg McWhirter wrote:

It built successfully using gcc 4.0.1 as well. Is there any way to check the functionality of the builds easily?

Go into the dirs and issue "make check".

[Greg McWhirter]

Ah, of course. I tried "make test" and didn't think of "make check". Those are running for the gcc 4.0.1 build currently. 

As for the logs, it doesn't seem any were saved. I can rebuild and force them to save if there is an efficient flag to pass (or is it enough to just "./configure > build.log && make >< build.log" or something similar)? 

- Greg

[leif]

(./configure && make) 2>&1 >build.log # or | tee -a build.log

Using 'sage -i -s /path/to/new/mpir/spkg' should IMHO work as well, provided you've built the few dependencies of MPIR in advance (e.g. by running 'make' from the Sage root directory until the MPIR error occurred.)

[The '-s' option keeps the (MPIR) build directory (which e.g. contains config.log) even if no errors occurred.]

-leif

- Greg

[Jean-Pierre Flori]

I thinkj mmake > build.log should be ok.
By default nothing is "saved", thats a thing Sage adds to the build process.

- Greg

[Greg McWhirter]

New logs are linked below. 

Doing "grep -A6 '^using ABI' build.log" results in the following on both gcc versions: 

using ABI="32"

      CC="gcc -std=gnu99"

      CFLAGS="-m32 -O2 -fomit-frame-pointer -mtune=nocona -march=nocona"

      CPPFLAGS=""

      MPN_PATH=" x86/applenopic generic"

checking for ar... ar

checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p

The "sage -i" also appears to work correctly.

Links to logs:

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_gcc_4.0.1.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_check_gcc_4.0.1.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_gcc_4.2.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_check_gcc_4.2.log (coming soon)

- Greg

[Jean-Pierre Flori]

On Monday, December 3, 2012 10:57:50 PM UTC+1, Greg McWhirter wrote:

New logs are linked below. 

Doing "grep -A6 '^using ABI' build.log" results in the following on both gcc versions: 

using ABI="32"

      CC="gcc -std=gnu99"

      CFLAGS="-m32 -O2 -fomit-frame-pointer -mtune=nocona -march=nocona"

      CPPFLAGS=""

      MPN_PATH=" x86/applenopic generic"

checking for ar... ar

checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p

The "sage -i" also appears to work correctly.

Links to logs:

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_gcc_4.0.1.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_check_gcc_4.0.1.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_gcc_4.2.log

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/build_check_gcc_4.2.log (coming soon)

- Greg

 Just by curiosity, could you test the spkg (or just trying to build MPIR included in the tarball) at:
http://boxen.math.washington.edu/home/jpflori/mpir-2.6.0.p2.spkg

I put back files with PIC specific code, but that do not use the GOT construction.

Best,
JP

[Greg McWhirter]

"./sage -i ./mpir-2.6.0.p2.spkg" appears to have worked fine. Log is linked below if you need it.

- Greg

Log: http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/mpir-2.6.0.p2.log

[Jean-Pierre Flori]

On Tuesday, December 4, 2012 12:04:33 AM UTC+1, Greg McWhirter wrote:

"./sage -i ./mpir-2.6.0.p2.spkg" appears to have worked fine. Log is linked below if you need it.

- Greg

Great!
Sorry for not asking this earlier but could you try running the test suite?
With Sage, you do
SAGE_CHECK=yes ./sage -i ....

Another option is to add some flag (don't remember which) to tell Sage to keep the build dir, then go there and launch make check by hand.

A last one is to copy the src dir from the spkg, go there and launch make and make check there.

[John H Palmieri]

On Monday, December 3, 2012 3:12:48 PM UTC-8, Jean-Pierre Flori wrote:

On Tuesday, December 4, 2012 12:04:33 AM UTC+1, Greg McWhirter wrote:

"./sage -i ./mpir-2.6.0.p2.spkg" appears to have worked fine. Log is linked below if you need it.

- Greg

Great!
Sorry for not asking this earlier but could you try running the test suite?
With Sage, you do
SAGE_CHECK=yes ./sage -i ....

It would be better to do "sage -i -c ...", since these days the self-tests for mpir are skipped by default (even with SAGE_CHECK=yes, I think).

Another option is to add some flag (don't remember which) to tell Sage to keep the build dir, then go there and launch make check by hand.

"sage -i -s ..." saves the build dir.
 
--
John

[Greg McWhirter]

Thanks. I figured this out after a couple tries. Ended up doing the following:

$ ./sage -f -s ./mpir-2.6.0.p2.spkg

$ cd spkg/build/mpir-2.6.0.p2

$ ../../../sage -sh # (stuff that follows is in the sage shell)

$ ./spkg-check | tee -a ./mpir-2.6.0.p2_check.log

$ ^D # (end sage shell)

This failed in the cxx directory it seemed, but the error message was apparently not in the log. It may have been a weird error due to how I ran things (something about a value being too big for a long or something).

I am currently rerunning the tests by:

$ cd spkg/build/mpir-2.6.0.p2

$ make clean

$ export ABI=32

$ ./configure && make

$ make check | tee -a ./check.log

This appears to have passed 100%.

Log links:

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/mpir-2.6.0.p2_check.log (first time with ./spkg-check and some extra stuff from more tries)

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/mpir-2.6.0.p2_check-2.log (second time with a manual "make check")

 

- Greg

[Dima Pasechnik]

On 2012-12-03, Greg McWhirter <gsmcw...@gmail.com> wrote:
> ------=_Part_247_25357132.1354556542760
> Content-Type: text/plain; charset=ISO-8859-1

>
> I tried to patch it, but autoreconf failed (too old by default on 10.5.8 it
> seems):
>
> $ autoreconf -i
> configure.in:32: error: Autoconf version 2.68 or higher is required
> configure.in:32: the top level
> autom4te: /usr/bin/gm4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> autoreconf: aclocal failed with exit status: 63
>
> $ autoreconf -V
> autoreconf (GNU Autoconf) 2.61
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software. You may redistribute copies of it under the terms of
> the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by David J. MacKenzie and Akim Demaille.
>
> I tried grabbing updated autoconf and automake from Homebrew and manually
> linking them to /usr/local so they are used by default, but then I ran into
> issues with libtool when running "make".

one can just build autoconf 2.68 from source without any homebrew or
whatever and install it into /usr/local. At least I managed that on OSX
10.6.8.
(this might need building more things from source, don't recall now what
exactly).

[Jean-Pierre Flori]

On Tuesday, December 4, 2012 1:21:36 AM UTC+1, Greg McWhirter wrote:

Thanks. I figured this out after a couple tries. Ended up doing the following:

$ ./sage -f -s ./mpir-2.6.0.p2.spkg

$ cd spkg/build/mpir-2.6.0.p2

$ ../../../sage -sh # (stuff that follows is in the sage shell)

$ ./spkg-check | tee -a ./mpir-2.6.0.p2_check.log

$ ^D # (end sage shell)

This failed in the cxx directory it seemed, but the error message was apparently not in the log. It may have been a weird error due to how I ran things (something about a value being too big for a long or something).

I am currently rerunning the tests by:

$ cd spkg/build/mpir-2.6.0.p2

$ make clean

$ export ABI=32

$ ./configure && make

$ make check | tee -a ./check.log

This appears to have passed 100%.

Log links:

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/mpir-2.6.0.p2_check.log (first time with ./spkg-check and some extra stuff from more tries)

http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/working/mpir-2.6.0.p2_check-2.log (second time with a manual "make check")

 

Thanks again for the new report!
It seems to indicate that it is sufficient to remove files involving @GOT, not all files involving PIC specific code, which is not really a surprise.

I have an hopefully final request.
Could you try the spkg at #13137 which should be included in Sage ( http://boxen.math.washington.edu/home/jpflori/mpir-2.6.0.p0.spkg ) ?
It is basically the previous p1, but it's just to be sure I've not broken something while updating it.

And thanks again for your help with tracking this down!!!

[Greg McWhirter]

So I untarred a new copy of the 5.4.1 source, grabbed the spkg and did "./sage -i -c -s mpir-2.6.0.p0.spkg". The result was a successful build, but that error about integer length came up in the tests again. It was captured in the log this time, and may be because the tests were not using ABI=32 or perhaps because I did not "make" in the sage source directory until the point that mpir-2.4 failed. I will investigate further later (as I have to go teach at the moment). A link to the log is below.

- Greg

Log Link: http://dl.dropbox.com/u/14744151/MPIR%20build%20logs/tests_fail/mpir-2.6.0.p0.log

[Greg McWhirter]

Both doing a manual "make check" in the extracted directory (and exporting ABI=32) and doing "make; sage -i -c -s mpir-2.6.0.p0.spkg" from the source root folder failed the tests similarly. My current guess is that the gcc version in OS X 10.5.8 by default doesn't understand "long long". This would seem to be confirmed by the fact that a standard build process tries to build a minimal mpir to compile a more up-to-date gcc for sage to use for the rest of everything (including rebuilding mpir). At least, that is what it appears to be doing from what I can tell. So, I am not sure how big a deal the test failures are.

- Greg

[Jean-Pierre Flori]

On Tuesday, December 4, 2012 10:40:17 PM UTC+1, Greg McWhirter wrote:

Both doing a manual "make check" in the extracted directory (and exporting ABI=32) and doing "make; sage -i -c -s mpir-2.6.0.p0.spkg" from the source root folder failed the tests similarly. My current guess is that the gcc version in OS X 10.5.8 by default doesn't understand "long long". This would seem to be confirmed by the fact that a standard build process tries to build a minimal mpir to compile a more up-to-date gcc for sage to use for the rest of everything (including rebuilding mpir). At least, that is what it appears to be doing from what I can tell. So, I am not sure how big a deal the test failures are.

- Greg

Yup, as soon as the build process on Sage finishes correctly and produces a working library I guess we can be satisfied.