[Fuego] dbench no longer builds on any of my boards

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Tue Mar 27 01:03:27 UTC 2018

> -----Original Message-----
> From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com]
> Sent: Tuesday, March 27, 2018 9:45 AM
> To: daniel.sangorrin at toshiba.co.jp; fuego at lists.linuxfoundation.org
> Subject: RE: dbench no longer builds on any of my boards
> > -----Original Message-----
> > From: Daniel Sangorrin
> >
> > > -----Original Message-----
> > > From: Tim.Bird at sony.com
> > > I should have held off ACK-ing the patches until my test runs completed.
> > >
> > > That issue you mentioned with  dbench requiring libpopt is a killer.
> >
> > Yes, it is  a killer.
> >
> > > The previous dbench was building for all of my boards, and this one
> > > doesn't build for any of them (OK - that's only 3 toolchains, but still).
> > >
> > > The default debian-armhf toolchain doesn't include popt.h, nor
> > > does the yocto project SDK for aarch64, nor does the default
> > > debian x86_64 toolchain.
> >
> > For debian toolchains all you need to do is install the libpopt-dev library.
> > Note, that I already tell you that  on the error message. We could add that
> > library to the Dockerfile and the arm toolchain installer script. However,
> > now I am thinking of a different approach. Currently I am fixing the kernel
> > build test, and I have added a "dependencies" item to test.yaml. The idea
> > is to keep track of the build dependences of each test separately not in
> > the Dockerfile where everything is mixed and we have no control.
> The profusion developers ran into the same issue, and started working on
> it.  Basically, I think the debian packages needed for test building should be
> separated from those in the base "Fuego distribution".  We can add
> libpopt-dev to the toolchain installer script (I have nothing against that).
> But in general this solution doesn't scale.   If we have thousands of tests,
> we can't be installing every library in existence.  Each test should indicate
> its own build dependencies (as you say), and we should only install the
> ones needed for the tests that are installed in the system.
> >
> > For Yocto generated SDK, you would need to add the library to your sdk. Or
> > easier, add the dbench test to your target filesystem.
> The problem with adding dbench to the target system is that this is
> not a solution for testing final products.  Final products should not have a bunch
> of extra testing binaries on them.  Most consumer products I've worked on
> have two configurations: the developer configuration and the production
> configuration.  The production configuration usually has all the testing material
> stripped out.  This is especially important for low-footprint devices.
> >
> > > Is there any way to work around or remove this dependency?
> > > Two options come to mind:
> > >  - patch the code to use something else
> > >  - include the popt code in the test sources, and build it before building
> > dbench.
> > >
> > > Let me know what you think.
> >
> > OK, I will work on that.
> Which item are you working on?  I was going to take a look at dbench and see
> how dependent it is on libpopt.  They just added this recently, so it might
> not be that tightly integrated yet

It seems popt is no longer maintained although still used by samba (dbench comes from here), rsync and other programs according to

Perhaps, the best would be to talk with the upstream developers and see if they would
accept a patch that uses a different argument parser.
What do you think?


More information about the Fuego mailing list