[MacPorts] #57612: libtool does not respect -syslibroot when linking

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
#57612: libtool does not respect -syslibroot when linking
--------------------+--------------------
 Reporter:  kencu   |      Owner:  (none)
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:
 Keywords:          |       Port:
--------------------+--------------------
 This ticket is 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
       ...
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/57612>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------
Changes (by kencu):

 * Attachment "libedit-universal-fail.log" added.


--
Ticket URL: <https://trac.macports.org/ticket/57612>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 If, however, we add the `-isysroot` into 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
 `-isysroot` had been added to the link command, and then it works:
 {{{
 /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang
 -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
 -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
 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
 -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)
 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
 }}}

 and

 {{{
 $ port -v installed libedit
 The following ports are currently installed:
   libedit @20170329-3.1_2+universal platform='darwin 18' archs='i386
 x86_64' date='2018-11-05T20:57:12-0800'
   libedit @20180525-3.1_0+universal (active) platform='darwin 18'
 archs='i386 x86_64' date='2018-11-15T15:46:50-0800'
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------
Changes (by kencu):

 * Attachment "libedit-universal-succeed.log" added.

 same build, with -isysroot added on to the compiler spec

--
Ticket URL: <https://trac.macports.org/ticket/57612>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------
Description changed by kencu:

Old description:

> This ticket is 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
>       ...
> }}}
New description:

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

--

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 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.

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: libtool does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: libtool does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking (was: libtool does not respect -syslibroot when linking)

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 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.

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------
Changes (by kencu):

 * cc: jeremyhu (added)


--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by ryandesign):

 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?

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:11>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 `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/
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:12>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 and same with `macports-clang-5.0`, which is as far back as this Mojave
 behemoth can go in time.

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:13>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by ryandesign):

 Replying to [comment:10 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.

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:15>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by kencu):

 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.

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:16>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #57612: clang does not respect -syslibroot when linking

MacPorts
In reply to this post by MacPorts
#57612: clang does not respect -syslibroot when linking
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by jeremyhu):

 > 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

--
Ticket URL: <https://trac.macports.org/ticket/57612#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS
12