Re: MIOpen symbols file and libstdc++-dev
Hi,
> 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.
> 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]?
Seems there is no obvious solution right now, should we suspend the symbol sannitization work?
> So one theoretical(!) solution would be to re-write tests such that they use public interfaces that touch the internal codepaths, another would be to make some of those internal interfaces public after all. Both of this would be an undue burden though.
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?
Best,
Xuanteng
[7]: https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/master/debian/control?ref_type=heads#L103-106
Reply to: