Yeah , thats what I thought , but it must of been something else that was broken , as for example nehalem and atom are not in there and we have no problems building them.I suppose it could be some broken OS effect.
I think it goes like this for example configfsf.guess is run to get x86_64-unknown--slackware-linux configfsf.sub is run to canonicalize it to x86_64-unknown-linux-gnu config.guess is run to refine the cpu to nehalem-unknown-linux-gnu So it shouldn't see the cpu type. Jason On Friday 27 August 2010 23:20:55 Bill Hart wrote: > I remember adding some of these thinking that we just needed them to > "pass through". Basically we were using names that it was unfamiliar > with. So it would fail. Adding them here allowed our specialised names > to pass through. That was the reasoning anyhow. > > Bill. > > On 27 August 2010 20:19, Jason <ja...@njkfrudils.plus.com> wrote: > > Doing the same for configfsf.sub we get > > > > > > diff config-5ac8187868dd8955d5051dfb4ff56e69abe80dbd/config.sub > > mpir/trunk/configfsf.sub > > 4a5,6 > > > >> # > >> # Copyright 2008 William Hart > > > > 10a13,14 > > > >> # In particular, this version of the file has been modified for the MPIR > >> # program. > > > > 24,25c28,29 > > < # Foundation, Inc., 59 Temple Place - Suite 330, > > < # Boston, MA 02111-1307, USA. > > --- > > > >> # Foundation, Inc., 51 Franklin Street, Fifth Floor, > >> # Boston, MA 02110-1301, USA. > > > > 303c307,308 > > < | clipper-* | cydra-* \ > > --- > > > >> | core2-* \ > >> | clipper-* | cydra-* \ > > > > 330c335,336 > > < | none-* | np1-* | nv1-* | ns16k-* | ns32k-* \ > > --- > > > >> | nocona-* \ > >> | none-* | np1-* | nv1-* | ns16k-* | ns32k-* \ > > > > 332,334c338,342 > > < | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ > > < | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* > > \ < | pyramid-* \ > > --- > > > >> | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ > >> | pentium4-* \ > >> | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* > >> \ | prescott-* \ > >> | pyramid-* \ > > > > 444c452,455 > > < cray | j90) > > --- > > > >> core-*) > >> basic_machine=i686-`echo $basic_machine | sed > >> 's/^[^-]*-//'` ;; > >> cray | j90) > > > > 793c804 > > < pentiumpro | p6 | 6x86 | athlon | athlon_*) > > --- > > > >> pentiumpro | p6 | 6x86 | athlon | k7 | k7_* |athlon_*) > > > > 799,801d809 > > < pentium4) > > < basic_machine=i786-pc > > < ;; > > 805c813 > > < pentiumpro-* | p6-* | 6x86-* | athlon-*) > > --- > > > >> pentiumpro-* | p6-* | 6x86-* | athlon-* | k7-*) > > > > 811,813d818 > > < pentium4-*) > > < basic_machine=i786-`echo $basic_machine | sed > > 's/^[^-]*-//'` < ;; > > 1102c1107 > > < *-unknown) > > --- > > > >> *-unknown | *-pc | *-apple) > > > > You can see that except for the very last diff , the only changes are > > that specific cpu models have been added , this is the wrong place to > > add them , and anyway some other models are missing and we know it works > > on all of them. So the only thing we have to worry about is the "unknown > > | pc | apple " bit. They dont have this anyway in the latest , so we > > may need to add it back in. The pc bit was added in svn rev 1805 > > following this thread > > > > http://groups.google.com/group/mpir- > > devel/browse_thread/thread/eeafdd119660cad9/6ecdea0122067d44?lnk=gst&q=*- > > pc+allready#6ecdea0122067d44 > > > > Which was a configure failure on a 32bit ASUS EE PC with atom cpu. I'll > > leave out the change for the moment , and see if it still works. If it > > doesn't then we should push this change upstream. > > > > Jason > > > > On Friday 27 August 2010 19:25:27 Jason wrote: > >> Hi > >> > >> Hopefully updating configfsf.guess and sub will help with the > >> recognition of mingw64 and possible some other system where we dont > >> test > >> > >> > >> diff config-5ac8187868dd8955d5051dfb4ff56e69abe80dbd/config.guess > >> mpir/trunk/configfsf.guess > >> 6c6 > >> < timestamp='2004-03-12' > >> --- > >> > >> > timestamp='2004-10-07' > >> > >> 20c20 > >> < # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA > >> 02111-1307, USA. --- > >> > >> > # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > >> > 02110-1301, > >> > >> USA. > >> 662c662,663 > >> < if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep > >> __LP64__ > >> > >> >/dev/null > >> > >> --- > >> > >> > echo "__LP64__" > $dummy.c > >> > if (CCOPTS= $CC_FOR_BUILD -E $dummy.c) | grep __LP64__ > >> > >/dev/null > >> > >> This shows we have mode no significant changes to configfsf.guess and I > >> can just replace it with the latest version , which has 6 years !!!! of > >> changes. > >> > >> configfsf.sub looks more difficult > >> > >> Jason > >> > >> On Friday 27 August 2010 16:18:48 Jason wrote: > >> > Hi > >> > > >> > The mingw64 build mostly works now , but there are a few minor > >> > problems still to sort out. In the x86_64w directory we should mirror > >> > the x86_64 directory so we can have builds for the atom , netburst > >> > etc . This should not involve any assembler conversions as so far I > >> > dont think there is any specific code for these cpu's. The fat build > >> > doesn't work yet , and we have duplicate symbols defined on the > >> > shared lib build. T-local test fails , and the mingw32 build is I > >> > suspect broken , as our config.guess cant distinguish between mingw32 > >> > and mingw64 > >> > > >> > Jason > >> > > >> > On Thursday 19 August 2010 15:08:48 Bill Hart wrote: > >> > > Yes, there is strong demand for a 'make' based solution on Windows, > >> > > but using MSVC as the compiler. > >> > > > >> > > If you would like to give it a go, I know lots of people would be > >> > > very appreciative. Jason has put in a kind of configure/make type > >> > > thing for Windows. So it is there already to some extent. > >> > > > >> > > Of course for some people, maintaining the visual IDE solutions is > >> > > absolutely imperative, and Brian has been doing this for the latest > >> > > version of MSVC for a long time. So that will still be needed. It > >> > > also makes writing a 'make' based solution about 1000 times easier. > >> > > > >> > > Bill. > >> > > > >> > > On 19 August 2010 12:20, degski <deg...@gmail.com> wrote: > >> > > > Hi Cactus, > >> > > > > >> > > >> The real problem here is that nobody is willing to put in the > >> > > >> effort involved in maintaining the Visual Studio 2008 build. > >> > > > > >> > > > Maybe that should read ...is that nobody, feeling qualified, is > >> > > > willing to... I would not mind to chip in, but like it says, do I > >> > > > think I can deliver? > >> > > > > >> > > >> Its essentially the same problem. > >> > > >> > >> > > >> There is strong demand for a 'make' based MPIR build on Windows > >> > > >> but, again, nobody has volunteered to develop this. > >> > > > > >> > > > Well, yes, but once realized, maintainability will go up a lot and > >> > > > the move to VS2012 or whatever can be smooth and painless. > >> > > > > >> > > > I guess it would require somebody with a good understanding of the > >> > > > build process required, who could give input to identifying the > >> > > > difficulties (I mean, put on "paper") in creating this Windows > >> > > > build process. In the SWI-Prolog build process, the main > >> > > > difficulty is/was dealing with the different build environments, > >> > > > once defined and (pre-)configuration automated, it works quite > >> > > > well. > >> > > > > >> > > > Like you say, it seems most agree that the project approach is > >> > > > hard to maintain going forward and that "There is strong demand > >> > > > for a 'make' based MPIR build on Windows". > >> > > > > >> > > > Cheers > >> > > > > >> > > > > >> > > > degski > >> > > > > >> > > > -- > >> > > > Eric Schmidt, the chief executive of Google, has issued a stark > >> > > > warning over the amount of personal data people leave on the > >> > > > internet and suggested that many of them will be forced one day > >> > > > to change their names in order to escape their cyber past. > >> > > > > >> > > > The Independent, 18th August 2010 > >> > > > > >> > > > -- > >> > > > You received this message because you are subscribed to the Google > >> > > > Groups "mpir-devel" group. To post to this group, send email to > >> > > > mpir-de...@googlegroups.com. To unsubscribe from this group, send > >> > > > email to mpir-devel+unsubscr...@googlegroups.com. For more > >> > > > options, visit this group at > >> > > > http://groups.google.com/group/mpir-devel?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "mpir-devel" group. To post to this group, send email to > > mpir-de...@googlegroups.com. To unsubscribe from this group, send email > > to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this > > group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
