[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
https://stackoverflow.com/questions/189972/argument-parsing-helpers-for-c-unix

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?

Thanks,
Daniel





More information about the Fuego mailing list