octave @4.4.0_3 fails to build when using Apple's clang compiler

[josephsacco]

System: late 2015 iMAC, OSX 10.13.5

octave @4.4.0_3 fails to build when using Apple's clang compiler

cavandish:~ jsacco$ /usr/bin/clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

The default build dies during 'configure':

checking for sgemm_ in -L/opt/local/lib -lvecLibFort... yes
checking whether LSAME is called correctly from Fortran... no
checking whether ISAMAX is called correctly from Fortran... no
checking whether SDOT is called correctly from Fortran... no
checking whether DDOT is called correctly from Fortran... no
checking whether CDOTU is called correctly from Fortran... no
checking whether ZDOTU is called correctly from Fortran... no
checking BLAS library integer size... 4
checking for sgemm_ in -L/opt/local/lib -lvecLibFort... yes
checking whether LSAME is called correctly from Fortran... no
checking whether ISAMAX is called correctly from Fortran... no
checking whether SDOT is called correctly from Fortran... no
checking whether DDOT is called correctly from Fortran... no
checking whether CDOTU is called correctly from Fortran... no
checking whether ZDOTU is called correctly from Fortran... no
checking BLAS library integer size... 4
checking for sgemm_ in -L/opt/local/lib -lvecLibFort... yes
checking whether LSAME is called correctly from Fortran... no
checking whether ISAMAX is called correctly from Fortran... no
checking whether SDOT is called correctly from Fortran... no
checking whether DDOT is called correctly from Fortran... no
checking whether CDOTU is called correctly from Fortran... no
checking whether ZDOTU is called correctly from Fortran... no
checking BLAS library integer size... 4
configure: error: BLAS and LAPACK libraries are required

See attached main.log and config.log for full details

-Joseph

[josephsacco]

main.log

[josephsacco]

config.log

[kencu (Ken)]

Seems to fail due to this:

ld: in '/System/Library/Frameworks//Accelerate.framework/Versions/A/Accelerate.tbd', unexpected token: !tapi-tbd-v3 for architecture x86_64

Please try this:

sudo port -v install ld64 +ld64_xcode
sudo port clean octave
sudo port -v install octave

and you should have better success, I hope.

ld64 from MacPorts is a bit too old to handle the output of modern Xcode bits. The error you usually see is in regards to that unexpected token: !tapi-tbd-v3 business.

By setting ld64 + ld64_xcode you get the Xcode default linker, which speaks tapi.

We should make ld64 + ld64_xcode the default on 10.13.

[josephsacco]

Ken,

While I was pondering over what to try next, I ran a build using Macport's clang-5.0. That worked... :-)

Per your suggestion I next updated 'ld64' to 'ld64 +ld64_xcode', cleaned octave, and started a build using Apple's clang. The new and improved ld64 allowed configure to complete without error. The build is ongoing as I type. I will report back when it completes.

-Joseph

[josephsacco]

As predicted, the build using Apple's clang with 'ld64 _ld64_xcode' completed without error.

FWIW... I also tried building using Macport's gcc7. 'configure' rejected Apple's vecLib. Instead, it found and used atlas @3.10.2_2, which I had installed last October. The build died while compiling a graphicsMagick support file. If the details are useful, I can rerun the gcc7+atlas build and submit the log file.

-Joseph

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I am glad it is working now.
However, I would also like to have some sort of warning if possible.

Do you know how /System/Library/Frameworks//Accelerate.framework/Versions/A/Accelerate.tbd came into existence?

When I run mdfind Accelerate.tbd, I get

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/PrivateFrameworks/Swift/libswiftAccelerate.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate.tbd

When I run ls /System/Library/Frameworks/Accelerate.framework/Versions/A/, I get

Accelerate*     Frameworks/     Headers/        Modules/        Resources/      _CodeSignature/

By any chance, do you have some sort of nonstandard installation?

[josephsacco]

Marcus,

There is nothing odd about the installation of OS X on my iMac that I can think of. I do have the latest version of Xcode installed along with its associated command line tools.

The current date on /System/Library/Frameworks//Accelerate.framework/Versions/A/Accelerate.tbd is May 19,2018. Looking back in time using Time Machine, I see that this file first appeared on June 5, 2018. On that date there was an update of the Command Line Tools

Command Line Tools (macOS High Sierra version 10.13) beta 1 for Xcode
Version 10.0
Installed Jun 5,2018

-Joseph

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Thank you for the research.
I do not have a machine with Xcode 10, but this ticket will be useful when it is released.
Since Xcode 10 is still beta software, and you and Ken have found a workaround, can this ticket be closed?

[josephsacco]

I am OK with closing the ticket, but I would defer to Ken... :-)

Be well,

-Joseph

[kencu (Ken)]

The underlying problem is not Xcode 10, but the fact that when a port lists a dependency on ld64, on 10.13 any version other than ld64 +ld64_xcode is likely to cause troubles.

It would almost be better if ld64 (and cctools, probably) were empty ports on 10.13.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to kencu:

The underlying problem is not Xcode 10, but the fact that when a port lists a dependency on ld64, on 10.13 any version other than ld64 +ld64_xcode is likely to cause troubles.

Fair point, but I wold humbly suggest that this ticket is not the way to address this issue.
Since this is not an octave specific issue, I would suggest we close this ticket and either

• Open a dedicated ticket that CCs the interested parties
• Address this on the mailing list
• Open a pull request with the changes you propose
• Magically find a way for Apple to update the open source versions of ​ld64 and ​cctools

Otherwise, I worry that this ticket is destined to be forgotten and forever open.

[kencu (Ken)]

All true. I have no troubles with this ticket being closed. It's a systemic issue, not specific to this ticket.

[ken-cunningham-webuse]

In 5698d9483b44984a826d0f41154a4381b7957223/macports-ports (master):

ld64: default to +ld64_xcode on Xcode9+

ld64 does not understand tapi in the open-source
versions at present.

closes: #56843
closes: #53784
closes: #56398
closes: #56277
see: #56647
see: #54510
see: #54506
see: #53151