Hello Pranav,
Many thanks on your work on this!
I believe the issue was that during runtime, the binaries were expecting
the library to be present under /usr/lib (which isn't the case as we are
still in build time), so I just appended "-Wl,R" in the tests' makefile
to try and force the binaries to use the libraries under debian/tmp.
Now the result is:
...
6 ms OK! OK!
47/52 23:04:41 rtreemove-spr
tmpfile:
800 ms OK! OK!
48/52 23:04:42 serialize
tmpfile:
8 ms OK! OK!
49/52 23:04:42 split-reconstruct
tmpfile:
502 ms OK! OK!
51/52 23:04:42 treemove-spr
tmpfile:
491 ms OK! OK!
52/52 23:04:43 treemove-tbr
tmpfile:
8 ms Skip
Tests done... it took 49042 ms
52/52 (100.00%) OK
Kind regards,
Shayan Doust
On 08/06/2020 22:27, Pranav Ballaney wrote:
> Hi,
> I've committed a few changes to 2to3.patch along with a test.patch file
> that I used to try and debug this.
> It reports the following errors while running test/runtest.py:
>
> obj/binary/binary-random: error while loading shared libraries:
> libpll_binary.so.0: cannot open shared object file: No such file or
> directory
> obj/optimize/blopt-5states: error while loading shared libraries:
> libpll_optimize.so.0: cannot open shared object file: No such file or
> directory
> obj/tree/parsimony-tree: error while loading shared libraries:
> libpll_tree.so.0: cannot open shared object file: No such file or directory
>
> Any ideas about this?
>
> Regards,
> Pranav
>
> On Mon, Jun 8, 2020 at 3:21 PM Andreas Tille <andreas@an3as.eu
> <mailto:andreas@an3as.eu>> wrote:
>
> Hi Shayan,
>
> On Sun, Jun 07, 2020 at 07:00:01PM +0100, Shayan Doust wrote:
> > I am having some issues with pll-modules[1], more specifically its
> test.
> > The test is ran during the build process but unfortunately
> displays all
> > unit tests as "fail" when using python3. However, using python2,
> only a
> > very few out of the many unit test pass.
> >
> > I have a feeling some binaries are not getting invoked properly (run
> > time for all the failed unit tests are identical (3 ms) whereas passed
> > unit tests (when executing it via python2 as an experiment) take a
> good
> > few hundred milliseconds to execute).
> >
> > Note that I have generated a 2to3 patch for runtest.py.
> >
> > Any help with this package is much appreciated as I'm not sure what is
> > going wrong with the supplied test/runtest.py.
>
> I'm a bit occupied with other things this week so I wonder whether
> Nilesh
> or Pranav will be able to have a look.
>
> Just one unrelated comment on your commit
> 1d1c5c9f0486a9dfd19c772e28d68fcf430bec9b with the description:
>
> Add shlibs depends for libpll-modules-examples as these binaries
> rely on dynamic linkage
>
> The original idea of these examples packages is to ship just the example
> code and may be the source code and a build command / makefile. Since
> libpll is a development library we want to test the *development*
> process. Shipping readily build code does not really test whether the
> development process with the installed library is working. Thus I'd
> recommend to make sure the package is Arch: all and no Depends:shlibs
> is needed and build the testing code instead.
>
> Kind regards and thanks for working on this package
>
> Andreas.
>
> --
> http://fam-tille.de
>
> ᐧ
Attachment:
0x6D7D441919D02395.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature