#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)
Change History (15)
Changed 6 years ago by josephsacco
comment:1 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | MarcusCalhoun-Lopez removed |
---|---|
Keywords: | octave clang removed |
Owner: | set to MarcusCalhoun-Lopez |
Status: | new → assigned |
comment:2 Changed 6 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
.
comment:3 Changed 6 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 6 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 6 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 6 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 6 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 6 years ago by josephsacco
I am OK with closing the ticket, but I would defer to Ken... :-)
Be well,
-Joseph
comment:9 follow-up: 10 Changed 6 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 Changed 6 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
, on10.13
any version other thanld64 +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 6 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 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
main.log