[RFC PATCH 0/4] [PIDNS] Trie and pidns-cache tests
Dmitry V. Levin
ldv at altlinux.org
Mon Aug 17 23:44:48 UTC 2020
On Tue, Aug 18, 2020 at 01:21:18AM +0200, Ákos Uzonyi wrote:
> On Tue, 18 Aug 2020 at 01:12, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > On Tue, Aug 18, 2020 at 12:12:17AM +0200, Ákos Uzonyi wrote:
> > > On Sat, 15 Aug 2020 at 18:27, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > On Sat, Aug 15, 2020 at 06:23:26PM +0200, Ákos Uzonyi wrote:
> > > > > On Sat, 15 Aug 2020 at 14:41, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > > > On Thu, Aug 13, 2020 at 05:32:38PM +0200, Ákos Uzonyi wrote:
> > > > > > > is it's OK to add ../trie.c ../trie.h to libtests_a_SOURCES?
> > > > > >
> > > > > > I suppose automake should be fine with it. What's your concern?
> > > > >
> > > > > Technically there is no problem, I just worried about including a file
> > > > > not in tests directory, as it hasn't been done before. But if you say
> > > > > it's OK, then everything is fine :).
> > > >
> > > > The only problem is that it won't be built with coverage support,
> > > > so it won't be shown in coverage reports.
> > >
> > > I found an another problem, github CI errors with:
> > >
> > > /usr/bin/ld: i386:x86-64 architecture of input file
> > > `libtests.a(libtests_a-trie.o)' is incompatible with i386 output
> > Interesting. Could you give a link to the full log?
I see, it just built ../libtests_a-trie.o once and used it several times.
> > However, we are probably not interested in running this test for compat
> > personalities. There is a loop in ./bootstrap that creates tests-m32 and
> > tests-mx32 directories, we could do something there to filter it out.
> Yes, I was also thinking about doing something in bootstrap. But I
> think it's easier to add a symlink, and it also solves the coverage
> support problem.
I agree adding a symlink is much easier way to fix the build, but I don't
see how it solves the coverage support problem.
More information about the Strace-devel