link error using usd 22.08-rc1 generated cmake configuration

[cpichard]

Description of Issue

Using the cmake configuration produced by usd-22.08-rc1 results in a link error on macOS

Steps to Reproduce

Create the files CMakeLists.txt and do_nothing.cpp

// CMakeLists.txt:
cmake_minimum_required (VERSION 3.14)
project(do_nothing)
find_package(pxr REQUIRED)
add_executable(do_nothing do_nothing.cpp)
target_link_libraries(do_nothing ${PXR_LIBRARIES})
target_include_directories(do_nothing PUBLIC ${PXR_INCLUDE_DIRS})

// do_nothing.cpp
int main() {
    return 0;
}

then create the makefile and compile:

cmake -Dpxr_DIR=/path/to/install
make

results in

[ 50%] Building CXX object CMakeFiles/do_nothing.dir/do_nothing.cpp.o
[100%] Linking CXX executable do_nothing
ld: library not found for -lMaterialXGenShader
clang: error: linker command failed with exit code 1 (use -v to see invocation)

System Information (OS, Hardware)

System Version: macOS 12.4 (21F79)
Kernel Version: Darwin 21.5.0
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Thread model: posix
Target: arm64-apple-darwin21.5.0
and
Target: x86_64-apple-darwin21.5.0

Package Versions

usd 22.08-rc1

[sunyab]

Hi @cpichard, can you confirm whether you're building with MaterialX support enabled or disabled?

[cpichard]

Hi @sunyab
MaterialX build was enable, the command was:
arch -x86_64 python build_scripts/build_usd.py --materialx --no-tutorials --no-examples --no-tests --build /somewhere/to/builds/USD-22.08-rc1 /somewhere/to/installs/usd-22.08-rc1
Thanks,
Cyril

[sunyab]

Filed as internal issue #USD-7502

[sunyab]

This is a regression from the introduction of imported targets for linking MaterialX v1.38.4+ in 02a9843

From what I understand there's no way to export transitive imported targets, so there isn't an easy fix for this. This deficiency (IMHO) is documented in a 2 year old discussion from the CMake folks here:

• https://gitlab.kitware.com/cmake/cmake/-/issues/20558
• https://gitlab.kitware.com/cmake/cmake/-/issues/20511

There are a few workarounds:

• Instead of linking against ${PXR_LIBRARIES}, which includes every library in USD, link against only the libraries that you need via ${PXR_<libname>_LIBRARY} instead. This is less convenient but better for your build since it'll avoid linking unnecessary libraries. The MaterialX issue will only show up if you end up linking against one of hdSt, usdMtlx, hdMtlx, or usdBakeMtlx, which is uncommon.

• If you do need to link against one of the MaterialX-related libraries, adding this to your CMakeLists.txt should find the necessary MaterialX targets: find_package(MaterialX REQUIRED). I tried this in the repro case and confirmed it fixed the issue. Note that this required changing the cmake command line to:

cmake -Dpxr_DIR=/path/to/install -DMaterialX_DIR=/path/to/install/lib/cmake/MaterialX

One possible fix would be to modify pxrConfig.cmake to call find_dependency(MaterialX) to ensure the MaterialX targets are discovered when building code that links against USD. However, this forces everyone who use pxrConfig.cmake to link against a USD build with MaterialX to specify MaterialX_DIR, even if they don't link against any of the libraries that use MaterialX. I think that's just broadening the scope of the regression.

So given all that, my inclination is to accept this change in behavior in 22.08 with the hopes of finding a better long-term solution for the next release. If anyone has feedback about any of this please let me know.

[cpichard]

Thanks a lot @sunyab,
When we build and install USD using the build_usd.py script with the --materialx option, the MaterialX libraries are copied/installed in the usd/lib installation folder, at least that is what I am seeing on macOS.
Adding the following cmake directive allows to link correctly:
target_link_directories(do_nothing PUBLIC ${pxr_DIR}/lib)
I was thinking that if the MaterialX libraries are packaged with USD, wouldn't it make sense to add them in ${PXR_LIBRARIES} as well ? Or at least adding a materialXConfig.cmake alongside pxrConfig.cmake ?
Thanks a lot,
Cyril

[meshula]

Looking at https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/CMakeLists.txt, the MaterialXConfig.cmake is installed to MATERIALX_GEN_CONFIG_PATH

configure_package_config_file(cmake/modules/MaterialXConfig.cmake.in
                              ${CMAKE_BINARY_DIR}/cmake/${CMAKE_PROJECT_NAME}Config.cmake
                              INSTALL_DESTINATION "${MATERIALX_GEN_CONFIG_PATH}"
                              PATH_VARS CMAKE_INSTALL_PREFIX CMAKE_PROJECT_NAME)

which is set to

set(MATERIALX_GEN_CONFIG_PATH "${MATERIALX_INSTALL_LIB_PATH}/cmake/${CMAKE_PROJECT_NAME}")

where MATERIALX_INSTALL_LIB_PATH is an option set to "lib".

set(MATERIALX_INSTALL_LIB_PATH "lib" CACHE STRING "Install lib path (e.g. 'libs', 'lib').")

I wonder if you check these variables in the CMakeCache.txt from your MaterialX build, if it will provide some clues as to why the Config.cmake didn't land where your build can see it? Is the "lib" in your

target_link_directories(do_nothing PUBLIC ${pxr_DIR}/lib)

coming from MATERIALX_INSTALL_LIB_PATH? I do wonder though if changing lib might cause other bits of MaterialX to be diverted to the wrong place. If it's not possible to redirect only the location of the MaterialXConfig.cmake file from option variables to MaterialX's cmake script, it might be necessary to raise an issue on the MatX repo?

[cpichard]

Hi @meshula,

I had a quick look at the CMakeCache.txt where MaterialX was built and the interesting variables are:

MATERIALX_GEN_CONFIG_PATH not found
MATERIALX_INSTALL_LIB_PATH:STRING=lib
CMAKE_PREFIX_PATH:UNINITIALIZED=/Users/picharc/installs/usd-22.08-rc1
CMAKE_INSTALL_PREFIX:PATH=/Users/picharc/installs/usd-22.08-rc1

I didn't realise when I read the reply, but MaterialXConfig.cmake is actually installed in ${pxr_DIR}/lib/cmake/MaterialX like @sunyab mentioned, my bad. When I originally tried adding find_package(MaterialX REQUIRED) it didn't work, but now with -DMaterialX_DIR=${pxr_DIR}/lib/cmake/MaterialX it does.

All good !

Thanks,

Cyril