chasen-base @2.3.3: clang: error: unknown argument: '-syslibroot'

[chrstphrchvz (Christopher Chavez)]

First noticed this in an Azure builds: ​https://paste.z0k.xyz/d52c7a4964e9 (the build for 10.13 High Sierra succeeded though: ​https://paste.z0k.xyz/701be7feaf54). I was able to reproduce this on my machine after disabling ccache (#58479); will attach main.log.

/usr/bin/clang++ -dynamiclib -flat_namespace -undefined suppress -o .libs/libchasen.0.0.1.dylib  block.lo chalib.lo connect.lo dartsdic.lo getid.lo getopt.lo grammar.lo init.lo iotool.lo jfgets.lo katuyou.lo lisp.lo literal.lo mmap.lo parse.lo print.lo tokenizer.lo  -L/opt/local/lib -liconv -lc -headerpad_max_install_names -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -install_name  /opt/local/lib/libchasen.0.dylib -compatibility_version 1 -current_version 1.1
clang: error: unknown argument: '-syslibroot'

[ryandesign (Ryan Carsten Schmidt)]

I guess the problem is that the -syslibroot flag is being passed to the compiler (which doesn't understand it) when it's meant for the linker (which would understand it). MacPorts is supplying that flag with the proper -Wl, prefix to indicate that it should only be passed to the linker, but the bundled libtool appears to be stripping that away. Upgrading to a newer chasen-base may fix this if newer chasen-base includes a newer bundled libtool, or we might convince the build to use MacPorts libtool instead.

MacPorts only uses the -syslibroot flag when it is necessary to use an SDK. Mojave is the first version of macOS on which it is always necessary to use an SDK, since as of Mojave headers are no longer installed in /usr/include. MacPorts also uses an SDK on older systems in certain scenarios, such as if you are building for a different OS version than the one you are running or if you are building universal on Mac OS X 10.4 PowerPC.