MIOpen symbols file and libstdc++-dev
Hi forks,
We’re going to have a symbol control file for MIOpen. I’ve filed a MR draft for introducing a new version 5.5.1+dfsg2-2 for this [1].
The symbol file generated by dpkg-gensymbols are large with 5000+ exported symbols. MIOpen upstream does not compile the library with hidden visibility as other ROCm packages like rocSPARSE [2]. This is because some MIOpen tests directly use the internal APIs [3]. So if we hide these APIs, the tests will fail to build.
Currently MIOpen use the version script to control which symbols to export [4]. Alternatively, we can add symbols referenced in tests into the “global” field. But I suspect the resulting symbol file will be almost the same large as the current one, as the tests call a wide range of internal APIs (I count the number of "undefined reference to” linking errors during building which is 4000+).
If the large symbol file and the mixing of public and internal APIs are acceptable, we can continue. Otherwise if we want a clean and precise symbol file with only public interfaces, we may need to remove the -test package or statically link the test executables against MIOpen with a second compilation pass. Do you have any ideas?
Besides, MIOpen currently depends on libstdc++-dev as runtime compilation with hipRTC requires some C++ headers (e.g., <limits>) to compile the HIP kernel codes, otherwise, running autopkgtest will report the error like this:
$ MIOpenDriver reduce -V 1 -t 1
MIOpen(HIP): Error [Compile] 'hiprtcCompileProgram(prog.get(), c_options.size(), c_options.data())' gridwise_generic_reduction_first_call_multiblock_reduce_partial_dims.cpp: HIPRTC_ERROR_COMPILATION (6)
MIOpen(HIP): Error [BuildHip] HIPRTC status = HIPRTC_ERROR_COMPILATION (6), source file: gridwise_generic_reduction_first_call_multiblock_reduce_partial_dims.cpp
MIOpen(HIP): Warning [BuildHip] In file included from /tmp/comgr-8e8b54/input/gridwise_generic_reduction_first_call_multiblock_reduce_partial_dims.cpp:29:
In file included from /tmp/comgr-8e8b54/include/tensor_descriptor_helper.hpp:4:
In file included from /tmp/comgr-8e8b54/include/common_header.hpp:10:
/tmp/comgr-8e8b54/include/data_type.hpp:14:10: fatal error: 'limits' file not found
14 | #include <limits> // std::numeric_limits
| ^~~~~~~~
1 error generated when compiling for gfx1030.
Nevertheless, nothing else depends on libstdc++-dev except for gcc/clang packages. As ROCm stack depends on LLVM 17 packages now, the libc++-17-dev package also provides the header file [5]. But it installs into a non-standard path, where hipRTC cannot find during runtime which leads the same error above. Maybe we can choose to add a hardcoded compilation option `-I/usr/lib/llvm-17/include/c++/v1` as we did for GPU architecture [6]?
Best,
Xuanteng
[1]: https://salsa.debian.org/rocm-team/miopen/-/merge_requests/7
[2]: https://github.com/ROCm/rocSPARSE/blob/develop/library/CMakeLists.txt#L98
[3]: https://salsa.debian.org/rocm-team/miopen/-/blob/master/test/activation.cpp?ref_type=heads#L68
[4]: https://salsa.debian.org/rocm-team/miopen/-/blob/master/src/CMakeLists.txt?ref_type=heads#L724-740
[5]: https://packages.debian.org/trixie/amd64/libc++-17-dev/filelist
[6]: https://salsa.debian.org/rocm-team/miopen/-/blob/master/debian/patches/0007-specify-the-gpu-arch-for-hipRTC.patch
Reply to: