Re: Building on OSX without package managers

[Richard Campbell]

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?