Opened 4 years ago
Closed 13 months ago
#61236 closed defect (invalid)
$xcodeversion does not calculate the proper version when Xcode.app is not present or not found.
Reported by: | mascguy (Christopher Nielsen) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.6.3 |
Keywords: | Cc: | chrstphrchvz (Christopher Chavez) | |
Port: |
Description (last modified by mf2k (Frank Schima))
After upgrading to Xcode 12.0 command-line tools, the OpenBLAS +native variant fails to build.
Perusing the log, it looks like it may be failing during the link phase. (Though please keep me honest, as I may be missing something.) Build log file is attached.
This error stands out:
:info:build ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd' for architecture x86_64
There's an outstanding ticket mentioning that error from 'ld', though it was logged two months ago. And it's not clear from the ticket whether the creator had one of the Xcode 12 Beta releases installed. (The official Xcode 12.0 release was just published on 9/17/2020, so they definitely weren't using the final version.)
In any case, here's the ticket, in case it's helpful:
Let me know if you folks need any additional info.
Attachments (2)
Change History (30)
Changed 4 years ago by mascguy (Christopher Nielsen)
Attachment: | OpenBLAS-0.3.10_1-build-main.log.gz added |
---|
comment:1 follow-up: 6 Changed 4 years ago by mascguy (Christopher Nielsen)
p.s. My apologies for the uncompressed log file. I tried replacing it with a gzipped version, but the original wasn't removed.
Meanwhile, I can't seem to figure out how to remove an attachment. Am I simply getting old, or... ?
comment:2 Changed 4 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:3 Changed 4 years ago by kencu (Ken)
please show us the result of
port -v installed | grep ld64
Thanks!
comment:4 Changed 4 years ago by mf2k (Frank Schima)
In the future, please use WikiFormatting and add the port maintainer(s) to Cc (port info --maintainers OpenBLAS
), if any.
comment:5 Changed 4 years ago by mf2k (Frank Schima)
Cc: | michaelld added |
---|---|
Description: | modified (diff) |
Owner: | set to NicosPavlov |
Status: | new → assigned |
comment:6 Changed 4 years ago by jmroot (Joshua Root)
Replying to mascguy:
p.s. My apologies for the uncompressed log file. I tried replacing it with a gzipped version, but the original wasn't removed.
Replacing only works if the filename is identical.
Meanwhile, I can't seem to figure out how to remove an attachment. Am I simply getting old, or... ?
I deleted it for you. I think only admins can delete attachments.
comment:7 follow-up: 22 Changed 4 years ago by mascguy (Christopher Nielsen)
Folks, thanks for the feedback, as well as the assistance!
Here's the info requested, along with other (hopefully) useful detail.
Versions of 'ld64' installed:
$ port -v installed | ggrep ld64 ld64 @3_3 (active) platform='darwin 19' archs='x86_64' date='2020-08-17T11:50:51-0400' ld64-latest @450.3_0+llvm90 (active) platform='darwin 19' archs='x86_64' date='2020-08-17T11:50:47-0400'
Ports selected:
$ port select --summary Name Selected Options ==== ======== ======= clang none mp-clang-10 mp-clang-7.0 mp-clang-8.0 mp-clang-9.0 none cython none cython27 cython37 none gcc none mp-gcc10 none llvm none mp-llvm-10 mp-llvm-7.0 mp-llvm-8.0 mp-llvm-9.0 none maven none maven32 none mpi none openmpi-mp-fortran none mysql none mariadb-10.5 none nosetests none nosetests27 nosetests37 none perl none none postgresql none postgresql12 none pygments none py38-pygments none pytest none pytest37 none python none python27 python27-apple python37 python38 none python2 python27 python27 python27-apple none python3 python38 python37 python38 none ruby none ruby27 none
MacOS version info:
$ uname -a Darwin MacPro28.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64 $ sw_vers ProductName: Mac OS X ProductVersion: 10.15.6 BuildVersion: 19G2021
And finally, I attached a full list of installed ports. Filename: ports-installed-10.15.6.txt.gz
Let me know if there's any additional info I can provide. Ditto for additional testing/troubleshooting that would help.
Changed 4 years ago by mascguy (Christopher Nielsen)
Attachment: | ports-installed-10.15.6.txt.gz added |
---|
comment:8 Changed 4 years ago by mascguy (Christopher Nielsen)
Also of note, OpenBLAS +native builds successfully in my other three MacOS releases:
MacOS Version | Xcode Version |
---|---|
10.12.6 | 9.2 |
10.13.6 | 10.1 |
10.14.6 | 11.3.1 |
In addition, OpenBLAS +native was built successfully on 10.15.6 with Xcode 11.6. (Albeit the previous minor release of OpenBLAS from June, 0.3.10_0.)
comment:9 Changed 4 years ago by kencu (Ken)
Thanks. Somehow, you have the incorrect version of ld64
installed. For Catalina, the default is the xcode
variant, which is what you need:
% port -v installed | grep ld64 ld64 @3_3+ld64_xcode platform='darwin 19' archs='x86_64' date='2020-08-18T21:47:33-0700' ld64-xcode @2_3 platform='darwin 19' archs='x86_64' date='2020-08-18T21:47:32-0700'
to get that, you can do this:
sudo port -f uninstall ld64-latest sudo port -f uninstall ld64 sudo port install ld64
and then you should be good to go. Please report back your success, and then we can close this ticket.
comment:10 Changed 4 years ago by mascguy (Christopher Nielsen)
Ken, I went ahead per your instructions, but the build still failed with the same error from 'ld64'. Then I noticed that your install of ld64 uses the +ld64_xcode variant, while mine did not.
Note that the ld64 port doesn't appear to be defaulting to that variant on MacOS 10.15.6. So if that's the intent, perhaps the Portfile needs to be updated?
$ port info ld64 ld64 @3_3 (devel) Sub-ports: ld64-97, ld64-127, ld64-236, ld64-274, ld64-latest, ld64-xcode Variants: ld64_127, ld64_236, ld64_274, ld64_97, ld64_xcode, universal Description: ld64 combines several object files and libraries, resolves references, and produces an ouput file. Homepage: http://opensource.apple.com/source/ld64/ Runtime Dependencies: ld64-latest Platforms: darwin License: APSL-2 Maintainers: Email: jeremyhu@macports.org, GitHub: jeremyhu Email: kencu@macports.org, GitHub: kencu
No worries though. And after forcibly uninstalling the ld64 ports again, followed by an explicit install of the +ld64_xcode variant, the OpenBLAS build succeeded.
Thanks again for the assistance!
comment:11 Changed 4 years ago by kencu (Ken)
You should not need to force the xcode variant on Catalina. If you do, there is some issue. It does default to the xcode variant on my Catalina system with current xcode.
So -- have you somehow specifically disabled that xcode variant with something in your variants.conf?
There was another user a few weeks ago on Catalina who also had the wrong ld64 installed, but his was defaulting properly, so easily fixed, whereas yours, for some reason, is not.
comment:12 Changed 4 years ago by kencu (Ken)
Cc: | michaelld removed |
---|---|
Owner: | changed from NicosPavlov to kencu |
Port: | ld64 added; OpenBLAS removed |
Summary: | OpenBLAS 0.3.10_1 +native Build Fails on MacOS 10.15.6 and Xcode 12.0 → ld64 not defaulting to ld64_xcode on Catalina, causing TAPI link errors |
comment:13 Changed 4 years ago by kencu (Ken)
Cc: | jeremyhu added |
---|
comment:14 Changed 4 years ago by kencu (Ken)
This is the test in the Portfile that is supposed to be setting that variant for you. Perhaps something is amiss...
# Xcode 11 has a newer ld64 than MacPorts currently supplies, so we use it if {[vercmp $xcodeversion 11.0] >= 0} { default_variants +ld64_xcode }
comment:15 Changed 4 years ago by mascguy (Christopher Nielsen)
Interesting.
My 'variants.conf' is as follows. Note that I haven't made any changes to the default:
$ cat /opt/local/etc/macports/variants.conf # MacPorts system-wide global variants configuration file. # Any variants listed here are applied to all port builds. As on the # command line, variants may be either enabled (+) or disabled (-), and # unsupported variants are simply ignored. # # Each line must be a space- or tab-delimited list of zero or more # variants. # # Example: # -x11 +no_x11 +quartz # +gcc48 # +universal
Dunno if this is notable, but when I installed 'ld64' without requesting variant 'ld64_xcode', three ports were installed:
- ld64
- ld64-latest
- ld64-xcode
Is that expected?
comment:16 Changed 4 years ago by kencu (Ken)
All I can think of just now is that somehow base is not finding your $xcodeversion
correctly. It should be 12, which is clearly >= 11.0...
If you feel like experimenting a bit, throw in a:
puts "Xcode version is " puts $xcodeversion
above that test in the Portfile and see what port info
dumps out as your $xcodeversion
.
comment:17 Changed 4 years ago by kencu (Ken)
BTW you find and edit the portfile like this:
bbedit `port file ld64`
or whatever you like to use as a text editor....
comment:18 Changed 4 years ago by mascguy (Christopher Nielsen)
Okay, now things make sense...
I added the lines to output the Xcode version, and the result is 'none'. After perusing some of the older MacPorts issues, I realized the problem: When installing Xcode, I include the version in the path. For example, Xcode 12 is located at '/Applications/Xcode-12.0.app'.
That's being done for several reasons, one being that it allows me to have multiple Xcode versions installed side-by-side. Indeed, in my 10.15 installation, two versions are installed:
/Applications/Xcode-11.6.app /Applications/Xcode-12.0.app
(I realize that side-by-side Xcode installs can be problematic, particularly in terms of user account preferences. But let's avoid that discussion, unless it's absolutely critical...)
In any case, the command-line tools are always installed at their standard location, '/Library/Developer/CommandLineTools'. Otherwise everything breaks. :-)
So... I suppose I could create a soft link at '/Applications/Xcode.app', referring to the latest/preferred version. Under 10.15, it would resolve to Xcode 12.
Let me know your thoughts, and thanks again for the assistance!
comment:19 Changed 4 years ago by mascguy (Christopher Nielsen)
Ken, I'm running with the soft link approach, and it solves the issue. So you can go ahead and close this ticket.
Thanks again!
comment:20 Changed 4 years ago by kencu (Ken)
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
I'll close it as "invalid" as it's not something to fix on our end -- but that doesn't mean it was an invalid issue. It's just our nomenclature.
comment:21 Changed 4 years ago by kencu (Ken)
Cc: | jeremyhu removed |
---|---|
Component: | ports → base |
Port: | ld64 removed |
Resolution: | invalid |
Status: | closed → reopened |
Summary: | ld64 not defaulting to ld64_xcode on Catalina, causing TAPI link errors → $xcodeversion does not calculate the proper version when Xcode is installed in a non-default path. |
actually -- we should be able to absorb this kind of thing in base, I think...
comment:22 Changed 4 years ago by chrstphrchvz (Christopher Chavez)
Replying to mascguy:
Versions of 'ld64' installed:
$ port -v installed | ggrep ld64 ld64 @3_3 (active) platform='darwin 19' archs='x86_64' date='2020-08-17T11:50:51-0400' ld64-latest @450.3_0+llvm90 (active) platform='darwin 19' archs='x86_64' date='2020-08-17T11:50:47-0400'
This is exactly what I observed as described in ticket:60893#comment:7, so I don't think it's just the reporter (or me).
Replying to kencu:
There was another user a few weeks ago on Catalina who also had the wrong ld64 installed, but his was defaulting properly, so easily fixed, whereas yours, for some reason, is not.
Not sure if I'm the user in question, because I manually installed ld64 +ld64_xcode
—it did not eventually default properly.
The other thing that might've been unusual about my setup is that I have only the command line tools, not the full Xcode, so $xcodeversion
is none
for me.
I would expect $xcodeversion
to be influenced using xcode-select
(likely a better way of switching Xcode versions than with links), if it isn't already; and for MacPorts in general to not rely on Xcode being at /Applications/Xcode.app.
comment:23 Changed 4 years ago by chrstphrchvz (Christopher Chavez)
Cc: | chrstphrchvz added |
---|
comment:24 Changed 4 years ago by kencu (Ken)
I (or somebody) would / will have to look into exactly where $xcodeversion gets sorted out in base, and see if it can be enhanced to work even when Xcode.app can't be found or isn't present.
As we build with the CLTs preferentially now, $xcodeversion should be based on those rather than the Xcode.app anyway, right?
comment:25 Changed 4 years ago by kencu (Ken)
OR -- we all need to understand that we can't use $xcodeversion this way, and come up with other methods to sort out what we want to do, I guess.
comment:26 Changed 4 years ago by kencu (Ken)
Summary: | $xcodeversion does not calculate the proper version when Xcode is installed in a non-default path. → $xcodeversion does not calculate the proper version when Xcode.app is not present or not found. |
---|
comment:27 Changed 4 years ago by kencu (Ken)
Owner: | kencu deleted |
---|---|
Status: | reopened → assigned |
comment:28 Changed 13 months ago by jmroot (Joshua Root)
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Base is setting xcodeversion as designed, and you can now use xcodecltversion if you want the CLT version.
OpenBLAS 0.3.10_1 +native build log