Fix for building libtiff with Xcode 12

[meshula]

Description of Change(s)

This fix elides an option from the build command line sent to libtiff, to deal with the --version-script option no longer being recognized as of Xcode 12.

Fixes Issue(s)

Ld /Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/Release/libtiff.5.2.5.dylib normal x86_64
cd /Users/dp/Projects/usd-py3env/src/tiff-4.0.7
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-macos10.15 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -L/Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/Release -F/Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/Release -filelist /Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/tiff.build/Release/tiff.build/Objects-normal/x86_64/tiff.5.2.5.LinkFileList -install_name /libtiff.5.2.5.dylib -Xlinker -rpath -Xlinker /Users/dp/Projects/usd-py3env/lib -Xlinker -rpath -Xlinker /Users/dp/opt/miniconda3/envs/usd-py3env/lib -Wl,--version-script=/Users/dp/Projects/usd-py3env/src/tiff-4.0.7/libtiff/libtiff.map -dynamiclib -Wl,-headerpad_max_install_names -install_name @rpath/libtiff.5.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libm.tbd /Users/dp/Projects/usd-py3env/lib/libz.dylib /Users/dp/Projects/usd-py3env/lib/libjpeg.dylib /Users/dp/opt/miniconda3/envs/usd-py3env/lib/liblzma.dylib -compatibility_version 5.0.0 -current_version 5.2.5 -Xlinker -dependency_info -Xlinker /Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/tiff.build/Release/tiff.build/Objects-normal/x86_64/tiff.5.2.5_dependency_info.dat -o /Users/dp/Projects/usd-py3env/build/tiff-4.0.7/libtiff/Release/libtiff.5.2.5.dylib
ld: unknown option: --version-script=/Users/dp/Projects/usd-py3env/src/tiff-4.0.7/libtiff/libtiff.map
clang: error: linker command failed with exit code 1 (use -v to see invocation)

** BUILD FAILED **

[jtran56]

Filed as internal issue #USD-6330

[drwave]

If you file a Radar with Apple, I can follow up, given that that os/tool-chain is in beta.

…

On Sep 11, 2020, at 10:56 PM, Nick Porcino ***@***.***> wrote: @meshula commented on this pull request. In build_scripts/build_usd.py <#1315 (comment)>: > + + if MacOS() or iOS(): + PatchFile("CMakeLists.txt", + [("option(ld-version-script \"Enable linker version script\" ON)", + "option(ld-version-script \"Enable linker version script\" OFF)")]) + That suggests another option... The problem is that d-version-script=ON invokes a command line option that in the latest version of the linker causes an exit. We wouldn't want the default configuration on Big Sur to be failuire, fixable only with an argument everyone would be forced to append... If I can ascertain the correct toolchain identifier, then a better fix would be to set the linker script on or off based on toolchain version. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOTF5CI5WQDXUKGKWITSFMEPVANCNFSM4RAX2MXQ>.

[meshula]

@drwave Looking at what the libtiff cmakefile is doing, it doesn't seem like it would be legit for Apple to update clang to match this corner case behavior. The script that ships with libtiff says:

# Check if LD supports linker scripts, and define automake conditional
# HAVE_LD_VERSION_SCRIPT if so.  This functionality is currently
# constrained to compilers using GNU ld on ELF systems or systems
# which provide an adequate emulation thereof.

I don't spot a value add there. I broadened the scope of this patch to skip the script on Windows as well.