Re: MIOpen symbols file and libstdc++-dev
Hi Xuanteng,
On 2024-07-02 06:31, Xuanteng Huang wrote:
>> On Jul 1, 2024, at 03:53, Christian Kastner <ckk@debian.org> wrote:
>>
>> So what is the package that "fixes" this? I assume that depending
>> directly on clang-17 would do so, but would this be too big of a dependency?
>
> Adding clang-17 (without libstdc++-dev) can successfully address the header issue. And I guess it’s not because we lack the header file but we miss the compiler to appropriately find the header.
I concur. Though now I fear I may have misled as both, because: what
about gcc?
Out of curiosity, I ran an ubuntu:noble container [8] and added the
upstream APT repo [9] to look at how the packages are specified there.
Installing miopen-hip actually installs gcc and g++, via a package
rocm-llvm which depends on all versioned libstdc++-*-dev.
And installing miopen-hip does not result in libhiprtc-builtins5
installed, so perhaps that miopen is built without hipRTC support.
>> Slightly tangential: If hipRTC by itself cannot be useful without this,
>> I guess the dependency should be fixed there.
>
> Agreed. So we should explicitly add this to the dependencies list of libhiprtc-builtins5 [7]?
That's what my intuition would say, but that's not how upstream does it
(doesn't necessarily mean that upstream does it right).
I'm going to need some more time to investigate the things above, and my
earliest chance is Thursday.
Technically, we could also temporarily disable support for hipRTC in the
package and figure this out later. It's still in experimental, after all.
> Seems there is no obvious solution right now, should we suspend the symbol sannitization work?
Yes, I think so.
> Actually the tests leverage a wide range of internal APIs (somehow “abuse”), so if we choose to make them public, there will also be a symbol file which is large as one with all symbols. Should we report this to upstream to remind them this is an unreasonable design?
That's how I would normally approach it. However, it's possible that
some do not consider this pattern necessarily false (even if I disagree
with it).
Also, I strongly suspect that upstream meant to have the tests only for
build-time checking, and never intended them to be used as standalone
programs like we do.
Best,
Christian
> [7]: https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/master/debian/control?ref_type=heads#L103-106
[8]: podman run --rm -it ubuntu:noble
[9]:
https://rocm.docs.amd.com/projects/install-on-linux/en/latest/how-to/native-install/ubuntu.html
Reply to: