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

Tim.Bird at sony.com Tim.Bird at sony.com
Tue Mar 27 01:59:23 UTC 2018



> -----Original Message-----
> From: Daniel Sangorrin on Monday, March 26, 2018 6:03 PM
> > -----Original Message-----
> > From: Tim.Bird at sony.com 
> > > -----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?

if popt is no longer maintained, it will be increasingly difficult to obtain
or see pre-integrated into toolchains and SDKs.  I think the approach
of removing the dependency from dbench is best.

 -- Tim



More information about the Fuego mailing list