SuiteSparse @4.2.1_3 fails with undefined symbol

[flatjunk1@…]

Apparently same as ticket:45728, similar to ticket:39072 (SuiteSparse 4.1.0_0). Fixes proposed in latter did not work for me.

Attempting to install octave (sudo port install octave +atlas+docs). Fails repeatedly despite cleaning SuiteSparse and updating ports. Occurred in Yosemite 10.10.1, and still in 10.10.2. Xcode 6.1.1.

Logs and consoles attached. First attempt shown in console was to clean SuiteSparse then install octave. Second attempt follows directions per the "fix" of ticket:39072.

Stymied. Solution MUCH appreciated.

[flatjunk1@…]

Just realized the four attachments filenames may be confusing. They are in order and should be read as

a)... b)... c)... d)...

[seanfarley (Sean Farley)]

So, ATLAS seems to be throwing a wrench into this whole mess. I will need to recompile ATLAS ... which will probably take all night for me. If someone else can debug, that'd be great.

[michaelld (Michael Dickens)]

Just out of curiosity, what do the following return:

nm -a /opt/local/lib/libtatlas.dylib | grep dgemm
lipo -info /opt/local/lib/libtatlas.dylib

[flatjunk1@…]

Replying to michaelld@…:

Just out of curiosity, what do the following return:

nm -a /opt/local/lib/libtatlas.dylib | grep dgemm
lipo -info /opt/local/lib/libtatlas.dylib

Not sure what that's supposed to do, but no joy:

kflaton% nm -a /opt/local/lib/libtatlas.dylib | grep dgemm
nm: object: /opt/local/lib/libtatlas.dylib malformed object (unknown load command 9)

and

kflaton% lipo -info /opt/local/lib/libtatlas.dylib
Non-fat file: /opt/local/lib/libtatlas.dylib is architecture: x86_64

[michaelld (Michael Dickens)]

OK; well that's the issue then: libtatlas is corrupt. So, let's go back a step & see if that issue can get fixed. What does "port installed atlas" return for you?

[flatjunk1@…]

Replying to michaelld@…:

OK; well that's the issue then: libtatlas is corrupt. So, let's go back a step & see if that issue can get fixed. What does "port installed atlas" return for you?

I get:

kflaton% port installed atlas
The following ports are currently installed:
  atlas @3.10.2_1+clang+nofortran (active)

[flatjunk1@…]

Replying to flatjunk1@…:

Replying to michaelld@…:

OK; well that's the issue then: libtatlas is corrupt. So, let's go back a step & see if that issue can get fixed. What does "port installed atlas" return for you?

I get:

kflaton% port installed atlas
The following ports are currently installed:
  atlas @3.10.2_1+clang+nofortran (active)

FWIW, I did a clean install of MacPorts less than a week ago...

[michaelld (Michael Dickens)]

So I'm thinking it's the +nofortran option that's the issue. Just a guess at this time without more testing / statistics.

Can you do the following:

sudo port clean suitesparse atlas octave
sudo port selfupdate
sudo port -f uninstall atlas @3.10.2_1+clang+nofortran
sudo port install atlas
sudo port install suitesparse +atlas

and see if that works. If so, then go forth with:

sudo port install octave +atlas

and then if that works make sure octave executes as desired.

[flatjunk1@…]

Chokes on installing atlas:

kflaton% sudo port install atlas
--->  Fetching archive for atlas
--->  Attempting to fetch atlas-3.10.2_1+clang.darwin_14.x86_64.tbz2 from http://packages.macports.org/atlas
--->  Attempting to fetch atlas-3.10.2_1+clang.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/atlas
--->  Attempting to fetch atlas-3.10.2_1+clang.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/atlas
--->  Fetching distfiles for atlas
--->  Verifying checksums for atlas
--->  Extracting atlas
--->  Applying patches to atlas
--->  Configuring atlas
Selected C compiler: /usr/bin/clang
Error: org.macports.configure for port atlas returned: Atlas could not detect any fortran compiler. If you really don’t need the fortran interface to be built, please use the +nofortran option, else install a fortran compiler (e.g. gcc4X) before building Atlas.
Please see the log file for port atlas for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/atlas/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port atlas failed

and then again while installing SuiteSparse:

kflaton% sudo port install suitesparse +atlas
--->  Computing dependencies for SuiteSparse
--->  Dependencies to be installed: atlas
--->  Configuring atlas
Selected C compiler: /usr/bin/clang
Error: org.macports.configure for port atlas returned: Atlas could not detect any fortran compiler. If you really don’t need the fortran interface to be built, please use the +nofortran option, else install a fortran compiler (e.g. gcc4X) before building Atlas.
Error: Failed to install atlas
Please see the log file for port atlas for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/atlas/main.log
Error: The following dependencies were not installed: atlas
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port suitesparse failed

(Thanks, btw.)

[michaelld (Michael Dickens)]

Grr ... the atlas Portfile should handle this condition. How about:

sudo port install gcc49
sudo port clean atlas suitesparse
sudo port install atlas +gcc49
sudo port install suitesparse +atlas

and see if that works.

[seanfarley (Sean Farley)]

Sigh, bitten again by the +nofortran variant.

[michaelld (Michael Dickens)]

"again"? seems like this would be a good one to get fixed properly ;)

[flatjunk1@…]

Ok, that did it! Megathanks. You totally da man!

[michaelld (Michael Dickens)]

On my system (OSX 10.8, Xcode 5.1.1), the +nofortran variant produces a library without the symbol "_dgemm_", so it won't work with suitesparse +atlas. I'm fixing suitesparse +atlas to check for +nofortran and bomb out when that happens so that we don't encounter this specific issue again (hopefully).

[michaelld (Michael Dickens)]

Done in r133519. Thanks for bringing this to our attention!

[seanfarley (Sean Farley)]

For future reference, by "again" I meant the ability to install atlas without a full lapack library (missing _dgemm_). Without removing the +nofortran variant or implement a 'lapack' port group, then each port that depends on atlas and needs a full lapack library needs to check for that variant.