ATLAS does not compile x86_64

[macport-snhhome@…]

atlas @3.8.3 +universal compile succeeds on snow leopard but the library /opt/local/lib/libatlas.dylib is only i386, not universal.

# nm -arch x86_64 /opt/local/lib/libatlas.dylib 
nm: file: /opt/local/lib/libatlas.dylib does not contain architecture: x86_64

# nm -arch i386 /opt/local/lib/libatlas.dylib
00424960 T _ATL_1dsplit
00424b00 T _ATL_Sgeadd
00413170 T _ATL_Sgemm
00424fa0 T _ATL_Sgescal
004253a0 T _ATL_Sgezero
00413b20 T _ATL_Ssymm
00414150 T _ATL_Ssyr2k
00414de0 T _ATL_Ssyrk
004163d0 T _ATL_Strmm
00416950 T _ATL_Strsm
<snip>

[jameskyle@…]

Please sync, universal variant has been disabled in atlas.

[macports@…]

Replying to jameskyle@…:

Please sync, universal variant has been disabled in atlas.

Why is this? 64 bit ATLAS is required to have a 64 bit python/numpy/scipy stack on snow leopard.

Since python is 64 bit by default this causes problems when trying to install numpy: Ticket #22165

Please consider bringing back the universal variant or another way to select 64 bit ATLAS (just need to change -b 32 and -m32 to 64)

[macports@…]

Cc Me!

[skymoo (Adam Mercer)]

Either this needs to be fixed, or atlas needs to be removed as a dependency for numpy. We can't have a numpy that doesn't work on SL.

[Veence (Vincent)]

Atlas is not at that time universal. It requires two steps in order to be built universal. First, compile a gcc43 or gcc44 with the --multilib option, so it can compile in both m32 and m64 mode. Next, Atlas itself must be compiled twice, once with -m32 and once with -m64. Unfortunately, this is not easy, even when muniversal1.0 is enabled.

[macports@…]

Would it be possible to have a 64 bit option rather than make a universal binary - ie a 64bit variant that just builds 64 bit (so we can have a 64bit python/numpy stack) or a default 32 bit variant as we are now.

I don't really need universal libraries but I would like to be able to get 64 bit atlas.

[ryandesign (Ryan Carsten Schmidt)]

Variants are not appropriate for selecting 64-bit vs. 32-bit. Instead, a port should examine the value of the ${build_arch} variable.

[jameskyle@…]

This should have fixed that:

​http://trac.macports.org/ticket/21433

​http://trac.macports.org/changeset/57851

I'll have to revisit.

[jameskyle@…]

I should also add that on my test machines, a macbook and a mac pro both running snow leopard I get full 64bit atlas/lapack/blas and a full 64bit numpy/scipy build that links only against the macports atlas libraries.

Also, the full scipy and numpy tests pass.

I am at this moment doing a from scratch clean build to try to duplicate this problem.

[jameskyle@…]

Atlas is not at that time universal. It requires two steps in order to be built universal. First, compile a gcc43 or gcc44 with the --multilib option, so it can compile in both m32 and m64 mode. Next, Atlas itself must be compiled twice, once with -m32 and once with -m64. Unfortunately, this is not easy, even when muniversal1.0 is enabled.

I didn't see the universal reference. The above quote is correct in that universal is not supported. On line 54 of the current portfile:

universal_variant no

Now, oddly enough, if I do a

port build atlas +universal

No error is thrown. This may be a bug with macports core as I would expect that it should produce an error if you disable the universal_variant. This doesn't seem to be unique to the universal variant too. I can successfully start building with this:

port build atlas +whateverIwant

Also, I can't seem to check for the universal variant if universial_variant no is set to alert the user that what they are doing will have no effect.

e.g. if {[variant_isset universal]} {} fails.

I'm not sure how to proceed. Should I enable the unviersal variant so I can check for it and warn the user then exit?

I would like to also assure, beyond a shadow of a doubt, that the atlas package will properly build 64 bit libraries if the ${build_arch} variable is set to do so and will build 32 bit if the build_arch is set for that and so the 64 bit numpy works as it should against these libraries.

[Veence (Vincent)]

Replying to jameskyle@…:

I didn't see the universal reference. The above quote is correct in that universal is not supported. On line 54 of the current portfile: universal_variant no

Now, oddly enough, if I do a

port build atlas +universal

No error is thrown. […] I'm not sure how to proceed. Should I enable the unviersal variant so I can check for it and warn the user then exit?

You can just warn the user via, e.g. reenabling universal_variant (otherwise you will not get it set whatever you do), and:

variant universal {
 ui_msg "Warning, Atlas does not build universal binaries."
}

and then set the flags according to the machine natural architecture.

I would like to also assure, beyond a shadow of a doubt, that the atlas package will properly build 64 bit libraries if the ${build_arch} variable is set to do so and will build 32 bit if the build_arch is set for that and so the 64 bit numpy works as it should against these libraries.

I didn't challenge that. I build Atlas in 64-bit mode very smoothly.

[jameskyle@…]

I think it might be better to exit on this error. Otherwise the message may easily pass on by without notice causing confusion.

We'll add the warning only first though. If confusion leads to tickets, I'll change to exiting as well.

Marked as fixed #r59800