clang-3.7 +universal: Undefined symbols for architecture i386

[TheLastLovemark]

When running port install py37-numpy +clang37 +gfortran +openblas +universal the following warning and error is generated:

--->  Applying patches to clang-3.7
Warning: reinplace s|/usr/bin/env python|/opt/local/bin/python2.7|g didn't change anything in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/llvm-3.7.1.src/tools/clang/tools/scan-build/set-xcode-analyzer
--->  Configuring clang-3.7
--->  Building clang-3.7
Error: Failed to build clang-3.7: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-3.7/clang-3.7/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port py37-numpy failed

I attached log files for clang and numpy

[kencu (Ken)]

You're trying to build i386 on 10.13 but you have Xcode 10 and no SDK with i386 support, it appears:

:debug:sysinfo macOS 10.13 (darwin/17.7.0) arch i386
:debug:sysinfo MacPorts 2.6.2
:debug:sysinfo Xcode 10.1

so this leads to an error:

ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd

Either you have to build as only 64bit, or you have to find and add the MacOSX10.13.sdk to the proper locations in

/Library/Developer/CommandLineTools/SDKs

and in Xcode as well.

[ryandesign (Ryan Carsten Schmidt)]

I'm removing the reference to py-numpy since this has nothing to do with it.

It doesn't even have anything to do with clang-3.7, nor with any other port specifically, but I'll leave that reference since that's the port that encountered the error.

Our understanding was that on macOS 10.13 /Library/Developer/CommandLineTools/SDKs/ should always contain MacOSX10.13.sdk, even if you have installed Xcode 10, provided you have also installed the macOS 10.13 version of the command line tools. I don't know why that appears not to be the case for you. You are not the first person to run into this. If you are able to figure out why you don't have the MacOSX10.13.sdk and/or how to install it properly, let us know.

Alternately, if you don't need the +universal variant here, then by all means don't use it.

[TheLastLovemark]

I came across this: ​https://github.com/phracker/MacOSX-SDKs, but I don't know how trustworthy it is. I am trying to find other sources

[TheLastLovemark]

I guess this verifies: ​https://apple.stackexchange.com/questions/358610/how-can-i-download-and-install-macos-10-12-sdk

[TheLastLovemark]

OK, so to to respond to your question: If you are able to figure out why you don't have the MacOSX10.13.sdk

I found this: ​https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_10.x_(since_Free_On-Device_Development) <--- show the section titled Xcode 7.0 - 10.x (since Free On-Device Development)

According to that, the SDK that ships with 10.1 is SDK macosx10.14.sdk.

I found macosx10.13.sdk at ​https://github.com/phracker/MacOSX-SDKs <--- scroll to bottom for individual archives of each available sdk.

I've downloaded, extracted and put the SDK folder in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

If that does not work, I will add it to the /Library/Developer/CommandLineTools/SDKs/ path also and try again

[kencu (Ken)]

you will need to add the MacOS10.13.sdk in both places.

You would do well to find it in an Apple location, such as the Xcode9 CLTs from their dev downloads website.

[TheLastLovemark]

Failed again.

Screen shot of SDK paths and log file attached

[TheLastLovemark]

SDK clang-3.7

[TheLastLovemark]

macosx10.13.sdk paths

[kencu (Ken)]

Your SDKs appear to be in the right place. The build at a certain point sets the isysroot to the MacOSX10.14.sdk, however, for some reason, instead of setting it to the MacOSX10.13.sdk, which it should look for and choose first according to base code.

So that's a puzzle at the moment.

Ryan's suggestion, for now, is that people on 10.13 who want to build +universal install and use XCode9 and the XCode9 CLTs, and don't upgrade Xcode (ever).

I have made the Xcode10 with added MacOSX10.13.sdk work on several systems, including on 10.14, but it's not clear to me at this moment why your build is failing to use the MacOSX10.13.sdk.

Sorry.

[TheLastLovemark]

I got it to work.

I used the official Apple version by extracting macosx10.13.sdk (10.13.4) from the XCode 9.4.1 CLT. Not the 10.13 SDK at ​https://github.com/phracker/MacOSX-SDKs

Then I renamed the default macosx10.14.sdk symlink and the Macosx.sdk folder/file.

Created a symlink for macosx10.13.sdk, then renamed macosx10.13.sdk to Macosx.sdk.

I'm not sure how long the build took, because I fell asleep.

Also not sure if the build would have worked if I did not rename folders (as opposed to the default and non-Apple)

=======================================================================================================

A few questions

Does xcode perform the SDK lookup or Macports?

If Macports, can it be enhanced to look for all SDKs in both paths and not just the most recent/default one that comes with the installed version of CLT?

Why does the 10.13.4 SDK work, but not the 10.14? What is different between the two?

Will I have to rename everything so that 10.14 is the default SDK or can I leave 10.13.4 in place? Will this cause problems?

=======================================================================================================

@Ryan Schmidt: you mentioned: Our understanding was that on macOS 10.13 /Library/Developer/CommandLineTools/SDKs/ should always contain MacOSX10.13.sdk, even if you have installed Xcode 10, provided you have also installed the macOS 10.13 version of the command line tools. I don't know why that appears not to be the case for you.

The High Sierra version of CLT available for XCode 10.1 ships with macosx10.14.sdk (10.14.x). I upgraded from Xcode 9 to XCode 10 for some other problem (I think I had to move from Sierra to HS and was forced to upgrade from MP 2.4x to 2.54)

[kencu (Ken)]

My guess is your problem was a bad MacOSX10.13.sdk from the internet. None of the other changes are needed (on my systems).

MacPorts, mostly, usually, for the most part, provides the SDK lookup, except in certain cases, which we are presently trying to overcome using the SDKROOT env var, and similar tricks.

The MacOSX10.13.sdk still has i386 support in it (headers, libraries with i386 binaries, etc). The MacOSX10.14.sdk and later do not have any i386 support.

[kencu (Ken)]

I think we can close this ticket, as there is nothing I can see to fix in clang-3.7, and the rest is a widespread "issue" for months and months now that has other tickets that we may or may not ever fix (providing non-default SDKs for Xcode).

[jmroot (Joshua Root)]

Replying to TheLastLovemark:

Does xcode perform the SDK lookup or Macports?

Both. MacPorts looks for the correct SDK in all the usual places, and if it can't find it, asks Xcode where it is. MacOSX.sdk is used as a last resort if the correct version can't be found.

However, if you have the Command Line Tools installed on 10.13, then /usr/include should exist, which should result in ${configure.sdkroot} being an empty string and no -isysroot flag being used.

Why does the 10.13.4 SDK work, but not the 10.14? What is different between the two?

The 10.14 SDK only supports building for x86_64. (Also it exposes symbols that are only available on 10.14 and later, which means it's a bad idea to use it to build on 10.13 unless the code being built knows to check for weak-linked symbols.)

[kencu (Ken)]

Replying to jmroot:

However, if you have the Command Line Tools installed on 10.13, then /usr/include should exist, which should result in ${configure.sdkroot} being an empty string and no -isysroot flag being used.

As you can well see from your initial issue that prompted this ticket in the first place, this is not sufficiently reliable to actually work through all cases (otherwise your clang +universal would have built without any need for the MacOSX10.13.sdk, which it did not).