[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MIOpen symbols file and libstdc++-dev



Hi Xuanteng,

Christian Kastner, on 2024-06-30:
> On 2024-06-30 05:23, Xuanteng Huang wrote:
> > 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?
> 
> Not me, unfortunately.
> 
> It seems we have conflicting goals: we want the library package to
> export only the public interface, whereas the tests here were designed
> to test internal interfaces.
> 
> I could be super-pedantic and/or wrong, but my impression was that unit
> tests should test only public interfaces. 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.
> 
> In the end, I think having tests is more important that symbol hygiene,
> so if we cannot find a solution, I'd vote for the former.

Passing by, I happen to have an idea.  Would it be possible to
attempt a construction of libraries with Link Time Optimization?
I believe this should trim down a bit the inflation of symbols,
but I'm not confident on the effects on MIOpen test suite.  That
would be enabled using in debian/rules for instance:

	export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

If the LTO builds is not an option due to interference with the
test suite, or still results in an unmanageable symbols file, I
would also agree with Christian it is better to have working
tests than extensive, and potentially energy draining, symbols
tracking.

Thank you for your work on the ROCm stack!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier@debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-    on air: Ayreon - Phase II: Symmetry

Attachment: signature.asc
Description: PGP signature


Reply to: