[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.9.6 build fails on an Opteron RHEL4
From: |
David Bateman |
Subject: |
Re: 2.9.6 build fails on an Opteron RHEL4 |
Date: |
Wed, 14 Jun 2006 11:09:23 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6-7.6.20060mdk (X11/20050322) |
Fredrik Lingvall wrote:
>John W. Eaton wrote:
>
>
>>| > Precisely what compiler is this?
>>| configure:2323: gcc -v >&5
>>| Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs
>>| Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>>| --infodir=/u
>>| sr/share/info --enable-shared --enable-threads=posix --disable-checking
>>| --with-s
>>| ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
>>| --enable-java-aw
>>| t=gtk --host=x86_64-redhat-linux
>>
>>I was asking about the Fortran compiler.
>>
>>
>>
>Since I did not specify it with F77= ... I guess the fortran compiler that
>comes with the gcc above is used.
>
>
>>| > When you specify --enable-64, Octave
>>| > is compiled to assume that Fortran integers are 8 bytes wide. Does
>>| > this compiler do that automatically, or have you provided the
>>| > appropriate flags for that? Also, are your custom BLAS and LAPACK
>>| > libraries compiled so that the integers are 8 bytes wide?
>>| >
>>| I use K. Goto's BLAS (and a LAPACK compiled against the GOTO BLAS lib).
>>
>>So, is it compiled in a way that ensures that the integer quantities
>>are 8 byte signed integers?
>>
>>
>>
>Goto BLAS auto detects the architecture when compiling and I have not
>thoroughly checked exactly what compiler flags that are used so I'm not
>sure
>(there is a lot of arch specific assembly code in Goto BLAS which I also
>haven't
>looked at).
>
>LAPACK, I have compiled with the -m64 flag and from gcc man,
>
>-m32'
>`-m64'
> Generate code for a 32-bit or 64-bit environment. The 32-bit
> environment sets int, long and pointer to 32 bits. The 64-bit
> environment sets int to 32 bits and long and pointer to 64 bits.
>
>so I guess it the depends on whether the "integer quantities" are declared
>as int:s or long:s.
>
>
For the sparse stuff in UFSparse you'll need to use the same flags to
gcc as you use to compile octave. In this case whether int or long is
64-bit will be autodetected and the correct versions of the UFSparse
code will be used for 64-bit. All of the UFSparse code we use has both
int and long versions available.
Regards
David
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
- 2.9.6 build fails on an Opteron RHEL4, Fredrik Lingvall, 2006/06/12
- Re: 2.9.6 build fails on an Opteron RHEL4, Geoffrey Knauth, 2006/06/12
- 2.9.6 build fails on an Opteron RHEL4, John W. Eaton, 2006/06/12
- Re: 2.9.6 build fails on an Opteron RHEL4, Fredrik Lingvall, 2006/06/13
- Re: 2.9.6 build fails on an Opteron RHEL4, John W. Eaton, 2006/06/13
- Re: 2.9.6 build fails on an Opteron RHEL4, Fredrik Lingvall, 2006/06/14
- Re: 2.9.6 build fails on an Opteron RHEL4,
David Bateman <=
- Re: 2.9.6 build fails on an Opteron RHEL4, Javier Fernández Baldomero, 2006/06/14
- Re: 2.9.6 build fails on an Opteron RHEL4, Francesco Potorti`, 2006/06/19
- Re: 2.9.6 build fails on an Opteron RHEL4, Javier Fernández Baldomero, 2006/06/20
Re: 2.9.6 build fails on an Opteron RHEL4, David Bateman, 2006/06/13