$xcodeversion does not calculate the proper version when Xcode.app is not present or not found.

[mascguy (Christopher Nielsen)]

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:

ticket:60893

Let me know if you folks need any additional info.

[mascguy (Christopher Nielsen)]

OpenBLAS 0.3.10_1 +native build log

[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... ?

[kencu (Ken)]

please show us the result of

port -v installed | grep ld64

Thanks!

[mf2k (Frank Schima)]

In the future, please use WikiFormatting and add the port maintainer(s) to Cc (port info --maintainers OpenBLAS), if any.

[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.

[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 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 18 21:21:34 PDT 2020; root:xnu-4570.71.82.5~1/RELEASE_X86_64 x86_64

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.

[mascguy (Christopher Nielsen)]

Also of note, OpenBLAS +native builds successfully in my other three MacOS installations:

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.)

[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.

[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!

[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.

[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
    }

[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?

[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.

[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....

[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!

[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!

[kencu (Ken)]

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.

[kencu (Ken)]

actually -- we should be able to absorb this kind of thing in base, I think...

[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.

[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?

[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.

[jmroot (Joshua Root)]

Base is setting xcodeversion as designed, and you can now use xcodecltversion if you want the CLT version.