Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#56647 closed defect (worksforme)

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

Reported by: josephsacco Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.5.2
Keywords: Cc:
Port: octave

Description

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

Attachments (2)

main.log (332.1 KB) - added by josephsacco 2 years ago.
main.log
config.log (178.8 KB) - added by josephsacco 2 years ago.
config.log

Download all attachments as: .zip

Change History (15)

Changed 2 years ago by josephsacco

Attachment: main.log added

main.log

Changed 2 years ago by josephsacco

Attachment: config.log added

config.log

comment:1 Changed 2 years ago by ryandesign (Ryan Schmidt)

Cc: MarcusCalhoun-Lopez removed
Keywords: octave clang removed
Owner: set to MarcusCalhoun-Lopez
Status: newassigned

comment:2 Changed 2 years ago by 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.

Last edited 2 years ago by kencu (Ken) (previous) (diff)

comment:3 Changed 2 years ago by 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

comment:4 Changed 2 years ago by 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

comment:5 Changed 2 years ago by 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?

comment:6 Changed 2 years ago by 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

comment:7 Changed 2 years ago by 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?

comment:8 Changed 2 years ago by josephsacco

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

Be well,

-Joseph

comment:9 Changed 2 years ago by 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.

comment:10 in reply to:  9 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by kencu (Ken)

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

comment:12 Changed 2 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: worksforme
Status: assignedclosed

comment:13 Changed 2 years ago by 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

Note: See TracTickets for help on using tickets.