Open frispete opened 4 years ago
I've made a little progress, -DOpenGL_GL_PREFERENCE=GLVND
was wrong, after switching to -DOpenGL_GL_PREFERENCE=LEGACY
, build progressed up until:
[ 193s] [ 49%] Linking CXX shared library libTestPlugDsoUnloadable.so
[ 193s] cd /home/abuild/rpmbuild/BUILD/USD-20.05/build/pxr/base/plug && /usr/bin/cmake -E cmake_link_script CMakeFiles/TestPlugDsoUnloadable.dir/link.txt --verbose=1
[ 193s] /usr/bin/c++ -fPIC -Wall -pthread -Wno-deprecated -Wno-deprecated-declarations -Wno-unused-local-typedefs -Wno-placement-new -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fas
ynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DNDEBUG -O2 -g -DNDEBUG -flto=auto -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now -shared -Wl,-soname,libTestPlugDsoUnloadable
.so -o libTestPlugDsoUnloadable.so CMakeFiles/TestPlugDsoUnloadable.dir/testenv/TestPlugDsoUnloadable.cpp.o -Wl,-rpath,/home/abuild/rpmbuild/BUILD/USD-20.05/build/pxr/base/tf:/home/abuild/rpmbuild/BUILD/USD-20
.05/build/pxr/base/arch: ../tf/libtf.so ../arch/libarch.so -ldl -lm /usr/lib64/libpython3.8.so /usr/lib64/libboost_python-py3.so.1.71.0 /usr/lib64/libtbb.so
[ 194s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: /tmp/libTestPlugDsoUnloadable.so.bFT7Hc.ltrans0.ltrans.o: in function `_GLOBAL__sub_I_TestPlugDsoUnloadable.cpp':
[ 194s] /home/abuild/rpmbuild/BUILD/USD-20.05/pxr/base/plug/testenv/TestPlugDsoUnloadable.cpp:40: undefined reference to `Unresolved_external_symbol_error_is_expected_Please_ignore()'
[ 194s] collect2: error: ld returned 1 exit status
[ 194s] make[2]: *** [pxr/base/plug/CMakeFiles/TestPlugDsoUnloadable.dir/build.make:113: pxr/base/plug/libTestPlugDsoUnloadable.so] Error 1
[ 194s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/USD-20.05/build'
[ 194s] make[1]: *** [CMakeFiles/Makefile2:4578: pxr/base/plug/CMakeFiles/TestPlugDsoUnloadable.dir/all] Error 2
Now, that's a beauty, isn't it. It's failing on a module, that's supposed to be failing?!?
Could some enlightened soul please bring some light into this dark corner?
That test succeeds by failing. Normally, it doesn't stop the build, but it sounds like your build environment has differences from the environment USD is usually built in. It might be an idea to elide that test and see if you can work through the rest of the build.
Progressing.. For some reason, this:
if (TARGET TestPlugDsoUnloadable)
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
set_target_properties(TestPlugDsoUnloadable
PROPERTIES
LINK_FLAGS "-undefined dynamic_lookup"
)
in pxr/base/plug/CMakeLists.txt
doesn't work as advertised, even with forcing LLVM 10.0 to compile this project.
Then I switched back to GCC 10.1.1 and tried this:
Index: b/pxr/base/plug/CMakeLists.txt
===================================================================
--- a/pxr/base/plug/CMakeLists.txt
+++ b/pxr/base/plug/CMakeLists.txt
@@ -105,6 +105,11 @@ if (TARGET TestPlugDsoUnloadable)
PROPERTIES
LINK_FLAGS "-undefined dynamic_lookup"
)
+ elseif ("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
+ set_target_properties(TestPlugDsoUnloadable
+ PROPERTIES
+ LINK_FLAGS "-Wl,--undefined,dynamic_lookup"
+ )
elseif (CMAKE_SYSTEM_NAME STREQUAL "Windows")
# This forces the link to complete but the linker will still
# report the missing symbol as an error and will also emit a
which fails as well, because -Wl,--no-undefined
is supplied later on, and ld seems to prefer later arguments over former ones. Nice.
Now I do:
# we cannot get any dirtier..
sed -i 's|-Wl,--no-undefined|-Wl,--undefined,dynamic_lookup|g' pxr/base/plug/CMakeFiles/TestPlugDsoUnloadable.dir/link.txt
between cmake and make. Obviously, because my toolchain-fu is lacking...
Update: finally getting somewhere. Disabling tests got rid of this issue.
The next issue is concerning the installation. USD seems to insist to install its libs into a ${CMAKE_INSTALL_PREFIX}/lib
destination, which will require another massaging to reorganize the correct layout, which would be ${CMAKE_INSTALL_PREFIX}/lib64
for 64bit builds.
/usr/lib/python
needs to be something like /usr/lib64/python3.8/site-packages
.
/usr/plugin/usd
needs to be something like /usr/share/usd/plugins
.
If I relocate all these items, I'm pretty sure, that this package will be dysfunctional.
Any more ideas?
I believe the key is GNUInstallDirs. If the USD CMake script isn't already using this : https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html then I believe the answer is to modify the script to use it on LInux. The LIBDIR variable from the GNUInstallDirs module should be lib64 as appropriate.
Filed as internal issue #USD-6207.
Well, I hit another major road block:
$ grep -E '.*Installing:.*/usr/lib64/.*\.so\.*' /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libarch.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libtf.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libgf.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libjs.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libtrace.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libwork.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libplug.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libvt.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libar.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libkind.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libsdf.so
[ 1381s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libndr.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libsdr.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libpcp.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusd.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdGeom.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdVol.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdLux.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdMedia.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdShade.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdRender.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdHydra.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdRi.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdSkel.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdUI.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdUtils.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libgarch.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhf.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhio.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libcameraUtil.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libpxOsd.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libglf.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhgi.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhgiGL.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhd.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhdSt.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libhdx.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdImaging.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdImagingGL.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdRiImaging.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdSkelImaging.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdVolImaging.so
[ 1382s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/USD-20.05-0.x86_64/usr/lib64/libusdAppUtils.so
None of the generated shared libs is versionized. This is going to produce a major headache for any Linux distribution, that attempts to build this lib for general consumption.
Usually, each library carries a version suffix after the .so, e.g.:
lrwxrwxrwx 1 root root 17 8. Jul 17:23 /usr/lib64/libAlembic.so -> libAlembic.so.1.7
lrwxrwxrwx 1 root root 20 8. Jul 17:23 /usr/lib64/libAlembic.so.1.7 -> libAlembic.so.1.7.12
-rwxr-xr-x 1 root root 1292376 8. Jul 17:23 /usr/lib64/libAlembic.so.1.7.12
The first item .so
is a symbolic link from the -devel
package, that is only used to link to a certain package in order to ease linking and to make sure, that files/interfaces, as defined in /usr/include, match the library. -devel
packages can exist only once in a system (alembic-devel
). The other files .so.1.7
and .so.1.7.12
are from a library package itself, where multiple versions can exist in a system installation. Therefor, they carry their version in the package name as well (e.g. libAlembic1_7
for this case).
I've no idea, how to handle your package. Will try to motivate other resources.
I can package everything into a single destination /opt/usd
, but this will never have a chance of getting a openSUSE standard component as such. I'm sure, this is true for most other distributions as well.
Did you hardcode the lib64 path or use the GnuInstallDirs utility? If the latter, would you consider a PR for that?
As to adding semantic versioning to the so's, it is probably more than we can solve in a back and forth on an issue. It might be good to take the conversation over to usd-interest for wider discussion. The reason I think it requires discussion is that it took us quite a long time on OpenEXR to get a solution that worked robustly across platforms and distributions, and even this year we discovered minor errors in our versioning system. So it would probably be best to approach it with the wider community, to make sure everyone is on the same page, and hopefully find collaborators on implementation.
I also get the error that pyside2-uic
cannot be found. This is on Ubuntu 20.04 LTS.
Packaging USD 20.05 on openSUSE Tumbleweed and friends requires to build manually, since downloading is not allowed. This is a typical requirement for reproducible builds et.al.
Attempting to build resulted in various issues.
On a python3 only target (openSUSE Tumbleweed), cmake isn't able to find the python interpreter:
fixed this.
FindTBB is unable to locate the system provided library:
fixed this.
Although, I've satisfied all dependencies (cmake doesn't complain anymore), the build fails:
Obviously, it doesn't provide the usual GL libraries. Further investigation showed, that
pxr/imaging/garch/CMakeLists.txt
references a variable${OPENGL_gl_LIBRARY}
, that isn't assigned anywhere. Hence I suppliedbut that didn't work.
The complete cmake invocation:
Additional notes:
usdview
depends onpyside2-uic
, which is gone upstream, since it can be replaced withuic -g python
.rcc
is a similar case.-lxxx
, wherexxx
is the libname without thelib
prefix and.so
suffix.The project is available here, the full build log here.