The problem is, this is the standard gcc in debian, :-(

On 3 June 2010 18:55, Jason Moxham <[email protected]> wrote:
> On Wednesday 02 June 2010 19:13:38 Bill Hart wrote:
>> On 2 June 2010 19:10, Jason Moxham <[email protected]> wrote:
>> > On Wednesday 02 June 2010 18:23:31 Bill Hart wrote:
>> >> Two comments:
>> >>
>> >> * Fat builds don't need to work on many systems. We only support x86
>> >> and x86_64 and basically people only need to be able to find one linux
>> >> machine with a working gcc to make one.
>> >
>> > True , but isn't the object format different for the bsd/mac ? , perhaps
>> > not?
>>
>> Not sure. It's not an argument to not support them. I just think it
>> isn't so important at the moment if we do.
>>
>> >> Q. Is that the difference between check and test, i.e. one is a fat
>> >> build and the other is a source build?
>> >
>> > One is a simple ./configure make make check make tune and the other is 4
>> > to 16 combinations of options ie C,fat,gcc,cc,icc,c++
>>
>> Ah ok.
>>
>> >> * I've never tried dropping the optimisation on gcc 4.3.2 to see if
>> >> the problem goes away.
>> >
>> > do we have gcc-4.3.2 on skynet ?
>>
>> Not that I know of.
>>
>> I guess you don't have access to FSFFrance.
>>
>> >> We could do that for that one version of gcc
>> >> perhaps?
>> >
>> > not sure how to drop the O level for one specific version of gcc without
>> > a small test case
>>
>> Yeah I have no idea.
>>
>
> we could kind  of  "fake" one up like , where we put the normal C files test
> case failures
>
> int     main(void)
> {
>
> #ifdef _GNUC_
> #if _GCC_VERSION_MAJOR==4 && _GCC_VERSION_MINOR==3 && _GCC_VERSION_PATCH==2
> #error BAD_GCC_VERSION
> #endif
> #endif
> return 0;}
>
> This would just gratuitously reject all gcc's which had this version number ,
> not a test as such , but it least it would not allow known bad mpir libs to be
> built , and the autotools script does falls back to "cc" which may work
>
> This would effectively "ban gcc-4.3.2"
>
>
>> >> Bill.
>> >>
>> >> On 2 June 2010 17:45, Jason Moxham <[email protected]> wrote:
>> >> > Looks good , there are only 2 or 3 real errors
>> >> >
>> >> > your cleo and iras errors are because you need to get icc in your path
>> >> >  , you will hit 1 real error then , but we can easily fix that.
>> >> >
>> >> > for lena and flavius gcc34 doesn't have a g++
>> >> >
>> >> > gcc54 has a broken c++
>> >> >
>> >> > gcc42 has a broken c++ and there is no way to get  a timer for tuning
>> >> > (same for cato)
>> >> >
>> >> > fulvia gcc4.5.0 is not installed right
>> >> >
>> >> > fulvia cc , 1 real error , suns assembler is old , we should force it
>> >> > to use yasm is all cases , I see if I can do it (I have to remove my
>> >> > brain first , to get in the autotools mood) , but it may have to wait
>> >> > for next release.
>> >> >
>> >> > bsd.math  we dont support fat builds on a mac (PIC code is different)
>> >> > and they arn't needed that much
>> >> >
>> >> > gcc101 is a bsd system and I think we dont support fat builds (same as
>> >> > above?) so possibly a real error
>> >> >
>> >> > rest of the machines use gcc-4.3.2 which is broken
>> >> >
>> >> > I have updated the test script to reflect some of changes , but there
>> >> > are a lot of broken systems , so we will still get some errors from
>> >> > these.
>> >> >
>> >> > Jason
>> >> >
>> >> > On Wednesday 02 June 2010 16:47:22 Minh Nguyen wrote:
>> >> >> Hi folks,
>> >> >>
>> >> >> Build and test results for MPIR 2.1.0-rc2 on the build farm are
>> >> >> available at
>> >> >>
>> >> >> http://wiki.sagemath.org/mpir/BuildFarm/mpir-2.1.0#MPIR2.1.0-rc2
>> >> >>
>> >> >> Each build was done using one thread, i.e. first exporting
>> >> >>
>> >> >> $ export MAKE='make'
>> >> >>
>> >> >> The test suite was ran using one CPU. On some machines, doing a
>> >> >> parallel build would result in a failure to tune, i.e. doing
>> >> >>
>> >> >> $ make tune
>> >> >>
>> >> >> after a parallel build would fail. So for each reported machine, I
>> >> >> only used one thread/CPU for build, check, tune, and test suite.
>> >> >>
>> >> >> --
>> >> >> Regards
>> >> >> Minh Van Nguyen
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "mpir-devel" group. To post to this group, send email to
>> >> > [email protected]. To unsubscribe from this group, send
>> >> > email to [email protected]. 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
>> > [email protected]. To unsubscribe from this group, send email
>> > to [email protected]. 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 [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en.

Reply via email to