[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