[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building on OSX without package managers
From: |
Richard Campbell |
Subject: |
Re: Building on OSX without package managers |
Date: |
Tue, 25 Jan 2011 18:10:12 -0500 |
On Jan 25, 2011, at 6:03 PM, John W. Eaton wrote:
> On 25-Jan-2011, Richard Campbell wrote:
>
> |
> | On Jan 25, 2011, at 12:40 PM, John W. Eaton wrote:
> |
> | > On 25-Jan-2011, Richard Campbell wrote:
> | >
> | > | The BLAS I am trying to compile against is the one built into OSX
> | > | (linked to by "-framework vecLib". If I try to compile with "-arch
> | > | x86_64" but without "--enable-64" I get the following error:
> | > |
> | > | configure: error: A BLAS library was detected but found incompatible
> | > | with your Fortran 77 compiler settings.
> | >
> | > This likely has nothing to do with --enable-64.
> | >
> | > Precisely how did you configure Octave in this case? Do you have
> | > -ff2c in your FFLAGS? I think your BLAS and LAPACK libraries were
> | > compiled with an older version of gfortran so used a different calling
> | > convention for some things which are now incompatible with they way
> | > gfortran works. See the explanation of -ff2c in the gfortran manual
> | > for more details.
> | >
> | > If -ff2c doesn't fix the problem, then post the parts of config.log
> | > that lead up to this error.
> | >
> | > Perhaps the README.MacOS should have a clearer description of why
> | > -ff2c is needed if you compile with Apple's veclib.
> | >
> | > jwe
> |
> | Yes, I am using -ff2c in my FFLAGS.
> |
> | It looks like there are two problems here, once of which is the SDOT
> function and one of which is the integer size.
> |
> | configure:45118: checking whether SDOT is called correctly from Fortran
> | configure:45138: gfortran -o conftest -arch x86_64 -ff2c -arch x86_64
> conftest.f -framework vecLib -lm >&5
> | configure:45138: $? = 0
> | configure:45138: ./conftest
> | STOP 1
> | configure:45138: $? = 1
> | configure: program exited with status 1
> | configure: failed program was:
> | | program main
> | |
> | | real sdot,a(1),b(1),w
> | | external sdot
> | | a(1) = 1e0
> | | b(1) = 2e0
> | | w = sdot(1,a,1,b,1)
> | | if (w .ne. a(1)*b(1)) stop 1
> | |
> | | end
> | configure:45147: result: no
> | configure:45150: checking whether DDOT is called correctly from Fortran
> | configure:45170: gfortran -o conftest -arch x86_64 -ff2c -arch x86_64
> conftest.f -framework vecLib -lm >&5
> | configure:45170: $? = 0
> | configure:45170: ./conftest
> | configure:45170: $? = 0
> | configure:45179: result: yes
> | configure:45182: checking whether CDOTU is called correctly from Fortran
> | configure:45202: gfortran -o conftest -arch x86_64 -ff2c -arch x86_64
> conftest.f -framework vecLib -lm >&5
> | configure:45202: $? = 0
> | configure:45202: ./conftest
> | configure:45202: $? = 0
> | configure:45211: result: yes
> | configure:45214: checking whether ZDOTU is called correctly from Fortran
> | configure:45234: gfortran -o conftest -arch x86_64 -ff2c -arch x86_64
> conftest.f -framework vecLib -lm >&5
> | configure:45234: $? = 0
> | configure:45234: ./conftest
> | configure:45234: $? = 0
> | configure:45243: result: yes
> | configure:45247: checking whether the integer size is correct
> | configure:45281: gfortran -o conftest -arch x86_64 -ff2c -arch x86_64
> conftest.f -framework vecLib -lm >&5
> | configure:45281: $? = 0
> | configure:45281: ./conftest
> | STOP 1
> | configure:45281: $? = 1
> | configure: program exited with status 1
> | configure: failed program was:
> | | program main
> | |
> | | integer n,nn(3)
> | | real s,a(1),b(1),sdot
> | | a(1) = 1.0
> | | b(1) = 1.0
> | | c Generate -2**33 + 1, if possible
> | | n = 2
> | | n = -4 * (n ** 30)
> | | n = n + 1
> | | if (n >= 0) goto 1
> | | c This means we're on 64-bit integers. Check whether the BLAS is, too.
> | | s = sdot(n,a,1,b,1)
> | | if (s .ne. 0.0) stop 1
> | | 1 continue
> | | c We may be on 32-bit integers, and the BLAS on 64 bits. This is almost
> bound
> | | c to have already failed, but just in case, we'll check.
> | | nn(1) = -1
> | | nn(2) = 1
> | | nn(3) = -1
> | | s = sdot(nn(2),a,1,b,1)
> | | if (s .ne. 1.0) stop 1
> | |
> | | end
> | configure:45290: result: no
> | configure:45500: error: BLAS doesn't seem to support 64-bit integers. This
> is incompatible with --enable-64.
>
> Did you use --enable-64 or not? If not, then this message is
> misleading, I thnk, because it should say that the BLAS does not
> appear to have 32-bit integers, not 64-bit integers.
>
> Also, note that the test is written to use sdot, so if the test for
> calling sdot correctly has already failed, that could be the reason
> for this test failure, not that there is anything wrong with the
> integer size.
>
> The tests should probably exit with different values so thatt we know
> precisely which test it is that is failing.
>
> After I sent my previous reply, I saw the following message from Jarno
> Rajahalme about how the Apple BLAS does not work correctly in 64-bit
> mode. See also the later message from him taht includes a link to a
> discussion about the issue.
>
>
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-January/022393.html
>
>
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-January/022458.html
>
> jwe
Yes, this is with --enable-64. As described earlier, I get a different error in
the same place if I try to build a 64-bit binary with and without --enable-64.
Is there an issue with the fact that LONG is a different size with 32 and
64-bit binaries? Can we just use INTEGER*4 and INTEGER*8 in the code itself,
depending on whether --enable-64 was specified, and decouple it from whether
the compiler is trying to produce a 32- or 64-bit binary?
- Re: Building on OSX without package managers, (continued)
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/24
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/25
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/25
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/25
- Re: Building on OSX without package managers, Ben Abbott, 2011/01/25
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/25
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers,
Richard Campbell <=
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers, bpabbott, 2011/01/25
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/24
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/24
- Re: Building on OSX without package managers, John W. Eaton, 2011/01/25
- Re: Building on OSX without package managers, Richard Campbell, 2011/01/25