#57612 closed defect (wontfix)
clang does not respect -syslibroot when linking
| Reported by: | kencu (Ken) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt), jeremyhu (Jeremy Huddleston Sequoia) | |
| Port: |
Description (last modified by kencu (Ken))
This ticket is to show some of the behaviour I've been noticing when trying to build on Mojave +universal against the MacOSX10.13.sdk, in particular to try to understand why the linking behaviour fails by default.
I picked a clean example, building libedit.
macports has been installed in /opt/universal, and macports.conf has two entries added:
macosx_deployment_target 10.13 macosx_sdk_version 10.13
variants.conf has one entry:
+universal
A copy of the MacOSX10.13.sdk is installed in the proper place in Xcode:
$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ total 0 drwxr-xr-x 5 root wheel 160 8 Nov 21:38 . drwxr-xr-x 5 root wheel 160 19 Oct 18:18 .. drwxr-xr-x 7 root wheel 224 30 Oct 19:25 MacOSX.sdk drwxr-xr-x 5 root wheel 160 8 Nov 21:37 MacOSX10.13.sdk lrwxr-xr-x 1 root wheel 10 25 Sep 22:31 MacOSX10.14.sdk -> MacOSX.sdk
libtool compiles correctly with the proper -isysroot
libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I/opt/universal/include -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -c readline.c -o readline.o >/dev/null 2>&1
The build tries to set up the link correctly. -isysroot and syslibroot are sent to libtool, and libtool passes only syslibroot along to clang to link, which should work:
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/clang -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -no-undefined -version-info 0:58:0 -L/opt/universal/lib -Wl,-headerpad_max_install_names -arch i386 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o libedit.la -rpath /opt/universal/lib chared.lo common.lo el.lo eln.lo emacs.lo hist.lo keymacro.lo map.lo chartype.lo parse.lo prompt.lo read.lo refresh.lo search.lo sig.lo terminal.lo tty.lo vi.lo wcsdup.lo tokenizer.lo tokenizern.lo history.lo historyn.lo filecomplete.lo readline.lo literal.lo -lncurses libtool: link: /usr/bin/clang -dynamiclib -o .libs/libedit.0.dylib .libs/chared.o .libs/common.o .libs/el.o .libs/eln.o .libs/emacs.o .libs/hist.o .libs/keymacro.o .libs/map.o .libs/chartype.o .libs/parse.o .libs/prompt.o .libs/read.o .libs/refresh.o .libs/search.o .libs/sig.o .libs/terminal.o .libs/tty.o .libs/vi.o .libs/wcsdup.o .libs/tokenizer.o .libs/tokenizern.o .libs/history.o .libs/historyn.o .libs/filecomplete.o .libs/readline.o .libs/literal.o -L/opt/universal/lib -lncurses -Os -arch i386 -Wl,-headerpad_max_install_names -arch i386 -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -install_name /opt/universal/lib/libedit.0.dylib -compatibility_version 1 -current_version 1.58 -Wl,-single_module
But does not, in the end, work. Instead, the MacOSX10.14.sdk is somehow called instead as the syslibroot to do the link, and this is the unexpected behaviour, which fails:
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
Undefined symbols for architecture i386:
"__DefaultRuneLocale", referenced from:
_ce__isword in chared.o
_cv__isword in chared.o
_cv__isWord in chared.o
_cv_next_word in chared.o
_cv_prev_word in chared.o
_cv__endword in chared.o
_ed_move_to_beg in common.o
...
Attachments (2)
Change History (34)
Changed 6 years ago by kencu (Ken)
| Attachment: | libedit-universal-fail.log added |
|---|
comment:1 Changed 6 years ago by kencu (Ken)
Changed 6 years ago by kencu (Ken)
| Attachment: | libedit-universal-succeed.log added |
|---|
same build, with -isysroot added on to the compiler spec
comment:2 Changed 6 years ago by kencu (Ken)
You might think this should work as well:
if {${configure.sdkroot} ne ""} {
configure.ldflags-append -isysroot${configure.sdkroot}
}
But it doesn't. Although that is passed to libtool, libtool does not pass it on to the link line, and the link fails:
libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I/opt/universal/include -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -c readline.c -o readline.o >/dev/null 2>&1
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/clang -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -no-undefined -version-info 0:58:0 -L/opt/universal/lib -Wl,-headerpad_max_install_names -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -arch i386 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o libedit.la -rpath /opt/universal/lib chared.lo common.lo el.lo eln.lo emacs.lo hist.lo keymacro.lo map.lo chartype.lo parse.lo prompt.lo read.lo refresh.lo search.lo sig.lo terminal.lo tty.lo vi.lo wcsdup.lo tokenizer.lo tokenizern.lo history.lo historyn.lo filecomplete.lo readline.lo literal.lo -lncurses
libtool: link: /usr/bin/clang -dynamiclib -o .libs/libedit.0.dylib .libs/chared.o .libs/common.o .libs/el.o .libs/eln.o .libs/emacs.o .libs/hist.o .libs/keymacro.o .libs/map.o .libs/chartype.o .libs/parse.o .libs/prompt.o .libs/read.o .libs/refresh.o .libs/search.o .libs/sig.o .libs/terminal.o .libs/tty.o .libs/vi.o .libs/wcsdup.o .libs/tokenizer.o .libs/tokenizern.o .libs/history.o .libs/historyn.o .libs/filecomplete.o .libs/readline.o .libs/literal.o -L/opt/universal/lib -lncurses -Os -arch i386 -Wl,-headerpad_max_install_names -arch i386 -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -install_name /opt/universal/lib/libedit.0.dylib -compatibility_version 1 -current_version 1.58 -Wl,-single_module
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
"__DefaultRuneLocale", referenced from:
_ce__isword in chared.o
_cv__isword in chared.o
_cv__isWord in chared.o
_cv_next_word in chared.o
_cv_prev_word in chared.o
_cv__endword in chared.o
_ed_move_to_beg in common.o
...
Likewise, libtool strips it out if the -isysroot is added to the cxxflags, or to the cflags. All those fail, as we saw previously in the original build failure.
comment:3 Changed 6 years ago by kencu (Ken)
| Description: | modified (diff) |
|---|
comment:4 Changed 6 years ago by kencu (Ken)
As I've thought about this more, it seems that perhaps libtool is actually doing the right thing, as far as it sees it. It does not think it should have to pass -isysroot to the linker, so it doesn't.
What is unexpected, then is that clang does not pass along the -syslibroot to the linker, it seems. It only works if clang sees -isysroot. I'll try to do some verbose builds and see if I can get a cleaner idea of what is being sent to whom.
comment:5 Changed 6 years ago by kencu (Ken)
It looks like if you don't pass -isysroot to clang during the link, but only pass syslibroot, it appends the syslibroot search path onto the library default search path, which fails:
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/clang -v -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -no-undefined -version-info 0:58:0 -L/opt/universal/lib -Wl,-headerpad_max_install_names -Wl,-v -arch i386 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o libedit.la -rpath /opt/universal/lib chared.lo common.lo el.lo eln.lo emacs.lo hist.lo keymacro.lo map.lo chartype.lo parse.lo prompt.lo read.lo refresh.lo search.lo sig.lo terminal.lo tty.lo vi.lo wcsdup.lo tokenizer.lo tokenizern.lo history.lo historyn.lo filecomplete.lo readline.lo literal.lo -lncurses
libtool: link: /usr/bin/clang -v -dynamiclib -o .libs/libedit.0.dylib .libs/chared.o .libs/common.o .libs/el.o .libs/eln.o .libs/emacs.o .libs/hist.o .libs/keymacro.o .libs/map.o .libs/chartype.o .libs/parse.o .libs/prompt.o .libs/read.o .libs/refresh.o .libs/search.o .libs/sig.o .libs/terminal.o .libs/tty.o .libs/vi.o .libs/wcsdup.o .libs/tokenizer.o .libs/tokenizern.o .libs/history.o .libs/historyn.o .libs/filecomplete.o .libs/readline.o .libs/literal.o -L/opt/universal/lib -lncurses -Os -arch i386 -Wl,-headerpad_max_install_names -Wl,-v -arch i386 -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -install_name /opt/universal/lib/libedit.0.dylib -compatibility_version 1 -current_version 1.58 -Wl,-single_module
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: i386-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
@(#)PROGRAM:ld PROJECT:ld64-409.12
BUILD 17:47:51 Sep 25 2018
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32
Library search paths:
/opt/universal/lib
/opt/universal/lib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib
Framework search paths:
/Library/Frameworks/
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
"__DefaultRuneLocale", referenced from:
_ce__isword in chared.o
_cv__isword in chared.o
_cv__isWord in chared.o
_cv_next_word in chared.o
_cv_prev_word in chared.o
_cv__endword in chared.o
_ed_move_to_beg in common.o
...
if you DO pass -isysroot to clang during the link, it replaces the default library search path (which is what you want) -- and then syslibroot adds it on again for us, for good measure:
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/clang -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -v -pipe -Os -arch i386 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -no-undefined -version-info 0:58:0 -L/opt/universal/lib -Wl,-headerpad_max_install_names -Wl,-v -arch i386 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o libedit.la -rpath /opt/universal/lib chared.lo common.lo el.lo eln.lo emacs.lo hist.lo keymacro.lo map.lo chartype.lo parse.lo prompt.lo read.lo refresh.lo search.lo sig.lo terminal.lo tty.lo vi.lo wcsdup.lo tokenizer.lo tokenizern.lo history.lo historyn.lo filecomplete.lo readline.lo literal.lo -lncurses libtool: link: /usr/bin/clang -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -v -dynamiclib -o .libs/libedit.0.dylib .libs/chared.o .libs/common.o .libs/el.o .libs/eln.o .libs/emacs.o .libs/hist.o .libs/keymacro.o .libs/map.o .libs/chartype.o .libs/parse.o .libs/prompt.o .libs/read.o .libs/refresh.o .libs/search.o .libs/sig.o .libs/terminal.o .libs/tty.o .libs/vi.o .libs/wcsdup.o .libs/tokenizer.o .libs/tokenizern.o .libs/history.o .libs/historyn.o .libs/filecomplete.o .libs/readline.o .libs/literal.o -L/opt/universal/lib -lncurses -Os -arch i386 -Wl,-headerpad_max_install_names -Wl,-v -arch i386 -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -install_name /opt/universal/lib/libedit.0.dylib -compatibility_version 1 -current_version 1.58 -Wl,-single_module Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: i386-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /opt/universal/lib /opt/universal/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS) libtool: link: (cd ".libs" && rm -f "libedit.dylib" && ln -s "libedit.0.dylib" "libedit.dylib") libtool: link: ar cru .libs/libedit.a chared.o common.o el.o eln.o emacs.o hist.o keymacro.o map.o chartype.o parse.o prompt.o read.o refresh.o search.o sig.o terminal.o tty.o vi.o wcsdup.o tokenizer.o tokenizern.o history.o historyn.o filecomplete.o readline.o literal.o libtool: link: ranlib .libs/libedit.a
So this looks like a clang ld driver bug to me at the moment...
comment:6 Changed 6 years ago by kencu (Ken)
| Summary: | libtool does not respect -syslibroot when linking → clang does not respect -syslibroot when linking |
|---|
comment:7 Changed 6 years ago by kencu (Ken)
This confusion goes back into antiquity. <https://lists.apple.com/archives/xcode-users/2005/Dec/msg00524.html> .
Perhaps there is a reason this works like this, on purpose. But it seems to me that if you specify a non-default syslibroot, it's because you want to use it instead of the default, not appended to it.
comment:8 Changed 6 years ago by kencu (Ken)
No doubt this is supposed to work. Here's the bit from man ld
-syslibroot rootdir
Prepend rootdir to all search paths when searching for libraries or frameworks.
Still trying to sort out exactly where the bug is. Is it in ld?
Perhaps the title here should be ld does not prepend syslibroot when linking.
comment:9 Changed 6 years ago by kencu (Ken)
| Cc: | jeremyhu added |
|---|
comment:10 follow-up: 14 Changed 6 years ago by kencu (Ken)
No, it's a clang driver thing. Take a simple example:
$ cat hello.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, World!";
return 0;
}
we compile that, and a default isysroot is helpfully added, to the 10.14 SDK, as you would expect:
$ clang++ -v -c hello.cpp Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -coverage-notes-file /Users/cunningh/hello.gcno -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -I/usr/local/include -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/cunningh -ferror-limit 19 -fmessage-length 195 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o hello.o -x c++ hello.cpp clang -cc1 version 10.0.0 (clang-1000.11.45.5) default target x86_64-apple-darwin18.2.0 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/v1" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
if you just link it, you get a nice default syslibroot, exactly like you would want:
$ clang++ -v -Wl,-v -o hello hello.o Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.14.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -o hello -v hello.o -L/usr/local/lib -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib Framework search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/
But if you try to force it to link against a different syslibroot, it is prepended by the default one, and it does not use the syslibroot you wanted it to:
$ clang++ -v -Wl,-v -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o hello hello.o Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.14.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -o hello -v -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk hello.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/
unless you also add an -isysroot, in which case your syslibroot was for nothing anyway:
$ clang++ -v -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -Wl,-v -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o hello hello.o Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.13.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o hello -v -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk hello.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ ld: warning: object file (hello.o) was built for newer OSX version (10.14) than being linked (10.13)
So the way to get what you want (at present) is to just use -isysroot, even for the link:
$ clang++ -v -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -Wl,-v -o hello hello.o Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.13.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o hello -v hello.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ ld: warning: object file (hello.o) was built for newer OSX version (10.14) than being linked (10.13)
and that works to give you your universal binaries:
$ clang++ -v -arch i386 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -Wl,-v -o hello hello.cpp Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple i386-apple-macosx10.13.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/cunningh -ferror-limit 19 -fmessage-length 195 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-fragile-10.13.0 -fobjc-subscripting-legacy-runtime -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/hello-b3f99e.o -x c++ hello.cpp clang -cc1 version 10.0.0 (clang-1000.11.45.5) default target x86_64-apple-darwin18.2.0 ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/v1" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory) End of search list. "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch i386 -macosx_version_min 10.13.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/-7c0252.out -v /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/hello-b3f99e.o -arch_multiple -final_output hello -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS) "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/cunningh -ferror-limit 19 -fmessage-length 195 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.13.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/hello-8ccfe5.o -x c++ hello.cpp clang -cc1 version 10.0.0 (clang-1000.11.45.5) default target x86_64-apple-darwin18.2.0 ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/v1" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory) End of search list. "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.13.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/-78252a.out -v /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/hello-8ccfe5.o -arch_multiple -final_output hello -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/ "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo" -create -output hello /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/-7c0252.out /var/folders/hp/684rvltd0c127nmt0bh3bpzm0000gn/T/-78252a.out
So using -Wl,-syslibroot -Wl,/path/to/SDK is basically useless at present, when using clang. Just use isysroot /path/to/SDK (which is broken because presently libtool strips it out of the link line).
comment:11 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Thanks for looking this. Have you checked wither the clang ports in MacPorts behave the same way? Have you checked whether the behavior changed at some point, in some version of clang?
comment:12 Changed 6 years ago by kencu (Ken)
macports-clang-7.0, at least, works just the same as Xcode 10's clang 1000+.
$ clang++ -v -Wl,-v -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -o hello hello.o clang version 7.0.0 (tags/RELEASE_700/final) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-7.0/bin "/opt/local/libexec/llvm-7.0/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-7.0/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.14.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -o hello -v -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk hello.o -lc++ -lSystem /opt/local/libexec/llvm-7.0/lib/clang/7.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:ld64-409.12 BUILD 17:47:51 Sep 25 2018 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em arm64e arm64_32 Library search paths: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib Framework search paths: /Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/
comment:13 Changed 6 years ago by kencu (Ken)
and same with macports-clang-5.0, which is as far back as this Mojave behemoth can go in time.
comment:14 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
we compile that, and a default isysroot is helpfully added, to the 10.14 SDK, as you would expect:
Where does that default isysroot come from? Because on 10.13, which has /usr/include, there is no default isysroot. It's only there on 10.14. But I don't know what puts it there.
comment:15 Changed 6 years ago by kencu (Ken)
Here's a useful option that can be passed to the link command that fixes this problem. I think it looks generic enough that it could nestle into base and should not cause any trouble. It fixes the build of libedit with libtool when added to portconfigure.tcl:
append_to_environment_value configure "LDFLAGS" -Wl,-syslibroot,${configure.sdkroot}
+ append_to_environment_value configure "LDFLAGS" -Wc,-isysroot,${configure.sdkroot}
comment:16 Changed 6 years ago by kencu (Ken)
I thought I'd hang this out for thoughts <https://github.com/macports/macports-base/pull/109> . This does seem to fix all the ports I've tested that used libtool to build and link against an SDK, and failed previously.
comment:17 follow-up: 25 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
A copy of the MacOSX10.13.sdk is installed in the proper place in Xcode:
$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
That will invalidate your Xcode.app bundle signature, meaning that updates from the store will download the update, fail to apply, then download the full app.
I suggest you place the 10.13 SDK at /Library/Developer/SDKs
As I've thought about this more, it seems that perhaps libtool is actually doing the right thing, as far as it sees it. It does not think it should have to pass -isysroot to the linker, so it doesn't
I thought I patched glibtool to pass that on to clang. glibtool needs to be updated to pass along -isysroot (if it isn't already). You'll need to run autoreconf or glibtoolize or similar to update with the installed glibtool.
comment:18 follow-up: 31 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Where does that default isysroot come from? Because on 10.13, which has /usr/include, there is no default isysroot. It's only there on 10.14. But I don't know what puts it there.
- If -isysroot is on the command line, it is used. Otherwise ...
- If system headers are installed, they are used (no sysroot is set). Otherwise ...
- If xcrun finds a major-version matching SDK in the selected in /Library/Developer/SDKs, it will use it. Otherwise ...
- If xcrun finds a macosx SDK in the selected Xcode.app or in /Library/Developer/SDKs, it will use it.
xcrun does not explicitly set the command line arguments. It sets the SDKROOT envvar, which CFE honors as the default isysroot if set.
comment:19 Changed 6 years ago by kencu (Ken)
Thanks for taking the time to spell that out -- that indeed explains a great deal.
comment:20 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Note that I lived on this very setup for about a year on my 10.13 system with a newer Xcode as part of validating the /Library/Developer/SDKs logic. That's not to say it is perfect, but it certainly was working for me. If you run into issues around the isysroot logic in xcrun or using the system matching SDK, I very much want to know about it, as it's possible that there are issues in xcrun itself that I can help fix in a future update.
comment:21 Changed 6 years ago by kencu (Ken)
If we put -isysroot into the LDFLAGS directly, and that somehow gets passed to ld by some port build system without being processed through clang, ld will error out.
ld -isysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk ld: unknown option: -isysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
I'm going to do some testing to see what happens we set the SDKROOT envvar in MacPorts then, but leave everything else alone.
If clang respects that envvar if set, and doesn't override it if it sees no -isysroot being passed, we could do that instead and change very little else in portconfigure.tcl.
comment:22 follow-up: 23 Changed 6 years ago by mouse07410 (Mouse)
Clang of Xcode-10.1 does not accept -syslibroot argument at all. That's what prevents gimp-print from being built on Mojave:
:info:build /usr/bin/clang -r -keep_private_externs -nostdlib -o .libs/libgimpprint.1.1.3.dylib-master.o print-lexmark.lo print-canon.lo print-dither.lo print-escp2.lo print-escp2-data.lo print-pcl.lo print-ps.lo print-util.lo print-color.lo print-weave.lo print-version.lo print-dither-matrices.lo && /usr/bin/clang -dynamiclib -flat_namespace -undefined suppress -o .libs/libgimpprint.1.1.3.dylib .libs/libgimpprint.1.1.3.dylib-master.o -L/opt/local/lib -liconv -lm -lc -headerpad_max_install_names -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -install_name /opt/local/lib/libgimpprint.1.dylib -compatibility_version 3 -current_version 3.3 :info:build clang: error: unknown argument: '-syslibroot' :info:build make[3]: *** [libgimpprint.la] Error 1 . . . . . $ ll /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk lrwxr-xr-x 1 root wheel 10 Oct 30 13:56 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk@ -> MacOSX.sdk $ ll /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk total 0 drwxr-xr-x 7 root wheel 224 Oct 18 08:52 ./ drwxr-xr-x 4 root wheel 128 Oct 30 13:57 ../ -rw-r--r-- 1 root wheel 127 Aug 17 19:45 Entitlements.plist -rw-r--r-- 1 root wheel 1150 Aug 17 19:45 SDKSettings.json -rw-r--r-- 1 root wheel 1326 Aug 17 19:45 SDKSettings.plist drwxr-xr-x 3 root wheel 96 Oct 18 08:52 System/ drwxr-xr-x 7 root wheel 224 Oct 18 08:52 usr/ $ clang -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -v clang: error: unknown argument: '-syslibroot' clang version 7.0.0 (tags/RELEASE_700/final) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-7.0/bin $ /usr/bin/clang -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -v clang: error: unknown argument: '-syslibroot' Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin $
On an unrelated issue - even though I set Macports clang to be the default, this port insists on using /usr/bin/clang. How to remedy this???
comment:23 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to mouse07410:
Clang of Xcode-10.1 does not accept
-syslibrootargument at all. That's what preventsgimp-printfrom being built on Mojave:
Yes, the compiler front end has never supported -syslibroot. How is that getting passed to clang?
comment:24 Changed 6 years ago by kencu (Ken)
somehow we've discussed this elsewhere as well, but it seems the libtool shipped with the software is very old. It can't be regenerated easily with .the old defs in the software, but luckily just using our current glibtool works correctly.
comment:25 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to jeremyhu:
Please do NOT use -Wl,-syslibroot. Please use -isysroot, so the driver and xcrun known what it is that you're requesting.
MacPorts base does use -Wl,-syslibroot. That's what Apple said to use when universal binaries started to be a thing in 10.4, and it used to work fine. If it changed at some point, that's annoying, but we would need to know what that point is so that MacPorts base can be updated to do the right thing, whatever the system or Xcode version.
comment:26 follow-up: 27 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
-Wl,-syslibroot continues to do what it always has. The issue is that passing it to xcrun does not stop xcrun from setting SDKROOT in the case where you are using an SDK to build. The best way to do that is to use -isysroot.
This behavior is really only relevant with Mojave because prior to Mojave, MacPorts users would install the DevSDK (headers at /). With Mojave +, we use the SDK directly. If an SDKROOT is not set (and not passed via canonical command line arguments), xcrun implicitly sets SDKROOT. If you intend to set the SDKROOT when invoking clang, you should do that with -isysroot instead of `-Wl,-syslibroot. The latter only passes that information to the linker whereas the former informs all stages of the build pipeline.
comment:27 Changed 6 years ago by kencu (Ken)
Replying to jeremyhu:
With Mojave +, we use the SDK directly.
This will force us to get it right, finally. Using an SDK has often not really worked as expected up until now, and now we know why not.
If you intend to set the SDKROOT when invoking clang, you should do that with
-isysrootinstead of `-Wl,-syslibroot. The latter only passes that information to the linker whereas the former informs all stages of the build pipeline.
And importantly, it passes the path to linker in such a way as it is nonfunctional, because it is overridden by clang anyway with an -isysroot (either the one you indicated, or one spec'd by xcrun). Either way, your syslibroot is not going to do anything useful (99% of the time, when cfe drives the linker).
comment:28 follow-up: 29 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Well, 99% of the time, the value you pass to -Wl,-syslibroot is the same as what xcrun would choose or what MacPorts passes explicitly.
I think the real problem here is that we are somehow in a state where MacPorts is trying to use an SDK that is different than what xcrun would be picking. The logic in xcrun pretty much picks what one would expect in MacPorts (ie: it will pick the one matching the host version if present and then fall back on the latest one if not).
Why are we in a situation where you are trying to use the 10.13 SDK on macOS 10.14? Perhaps if I understood that, we could improve the logic in xcrun.
comment:29 Changed 6 years ago by kencu (Ken)
Replying to jeremyhu:
Why are we in a situation where you are trying to use the 10.13 SDK on macOS 10.14? Perhaps if I understood that, we could improve the logic in xcrun.
We have a few important 32bit-requiring emulators like wine in particular and a few others to keep around while those projects get 64bit sorted out (and indeed they work nicely when you do get the SDK working). Homebrew can force-install software built on their 10.13 builders onto 10.14 systems, so that's what they are doing. MacPorts can't do that, though.
In general I would have guessed that a build system would prioritize a specified syslibroot path over an automatically-determined isysroot path for linking..but it's obviously not a major deal as it took us this long to figure out it didn't :>
comment:30 Changed 6 years ago by kencu (Ken)
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Closing as this is clang's expected behavior and there is nothing to fix in clang here.
comment:31 Changed 6 years ago by jmroot (Joshua Root)
Replying to jeremyhu:
- If -isysroot is on the command line, it is used. Otherwise ...
- If system headers are installed, they are used (no sysroot is set). Otherwise ...
- If xcrun finds a major-version matching SDK in the selected in /Library/Developer/SDKs, it will use it. Otherwise ...
- If xcrun finds a macosx SDK in the selected Xcode.app or in /Library/Developer/SDKs, it will use it.
Do you mean/Library/Developer/CommandLineTools/SDKs rather than /Library/Developer/SDKs? Because the former is where MacPorts seems to look.
comment:32 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yes. Sorry for any confusion.
If, however, we add the
-isysrootinto the link mix (which we know should not be needed), by adding this to the Portfile:# accept an sdkroot if one is set if {${configure.sdkroot} ne ""} { configure.cxx "${configure.cxx} -isysroot${configure.sdkroot}" configure.cc "${configure.cc} -isysroot${configure.sdkroot}" }presto -- we have success. The only difference I can see here is that now
-isysroothad been added to the link command, and then it works:and