[Buildroot] [PATCH v6] dieharder: new package

Julien Viard de Galbert julien at vdg.name
Mon Feb 6 20:56:31 UTC 2017


On Tue, Jan 24, 2017 at 11:40:06AM +1300, Thomas Petazzoni wrote:
> Hello,
> 
> Thanks a lot for all your iterations. It looks mostly good, but I have
> a few questions, see below.
> 
Hello,

See my comments bellow

> On Sun, 22 Jan 2017 13:14:42 +0100, Julien Viard de Galbert wrote:
> 
> > diff --git a/DEVELOPERS b/DEVELOPERS
> > index 91e82ac..75c8e71 100644
> > --- a/DEVELOPERS
> > +++ b/DEVELOPERS
> > @@ -868,6 +868,9 @@ F:	package/qt5/
> >  N:	Julien Floret <julien.floret at 6wind.com>
> >  F:	package/lldpd/
> >  
> > +N:	Julien Viard de Galbert <julien at vdg.name>
> > +F:	package/dieharder/
> > +
> 
> This should be in a separate patch, so that backporting the new package
> to an older version of Buildroot doesn't cause a conflict in the
> DEVELOPERS file.
> 
Ok I'll do that.

> > diff --git a/package/dieharder/0002-Do-not-install-includes.patch b/package/dieharder/0002-Do-not-install-includes.patch
> > new file mode 100644
> > index 0000000..6ece2a9
> > --- /dev/null
> > +++ b/package/dieharder/0002-Do-not-install-includes.patch
> > @@ -0,0 +1,28 @@
> > +From 9ee8200a6dec6aca7f4f37c46ca95ac1cb38306c Mon Sep 17 00:00:00 2001
> > +From: Julien Viard de Galbert <julien at vdg.name>
> > +Date: Sat, 14 Jan 2017 14:08:07 +0100
> > +Subject: [PATCH] Do not install includes
> > +
> > +We don't want include files on the target
> > +
> > +Signed-off-by: Julien Viard de Galbert <julien at vdg.name>
> 
> Why is this patch needed?
> 
> Header files are automatically removed from the target filesystem by
> the target-finalize logic in the main Buildroot Makefile. So there is
> no need to add special code in packages to remove header files.
> 
I'll double check I had this patch written almost 2 years ago when I first
tried to package dieharder, I remember the build system had several
glitches...

> Regarding the other patches, could you submit them to the upstream
> project? They all make sense for upstream I believe.
> 
I'll do it, yes.

> > +DIEHARDER_VERSION = 3.31.1
> > +DIEHARDER_SITE = http://www.phy.duke.edu/~rgb/General/dieharder
> > +DIEHARDER_SOURCE = dieharder-$(DIEHARDER_VERSION).tgz
> > +DIEHARDER_STRIP_COMPONENTS = 2
> > +DIEHARDER_LICENSE = GPLv2 with beverage clause
> 
> Interesting license :)
> 
> > +DIEHARDER_LICENSE_FILES = COPYING
> > +DIEHARDER_DEPENDENCIES = gsl host-libtool
> > +
> > +# Fix m4 links to points to the ones in staging (provided by libtool hence
> > +# the patch dependency).
> > +define DIEHARDER_POST_PATCH_FIXUP
> > +	for m in $(@D)/m4/*; do \
> > +		l=$$(readlink $$m) ;\
> > +		rm $$m ;\
> > +		ln -s $(HOST_DIR)$$l $$m ;\
> > +	done
> > +endef
> > +DIEHARDER_POST_PATCH_HOOKS += DIEHARDER_POST_PATCH_FIXUP
> 
> This looks weird. I haven't looked at the package in details though.
> Could you explain a bit more what's going on.
Well the package ships symbolic links to the host libtool:
libtool.m4 -> /usr/share/aclocal/libtool.m4
lrwxrwxrwx 1 julien julien 33 oct.  17  2015 lt~obsolete.m4 -> /usr/share/aclocal/lt~obsolete.m4
lrwxrwxrwx 1 julien julien 31 oct.  17  2015 ltoptions.m4 -> /usr/share/aclocal/ltoptions.m4
lrwxrwxrwx 1 julien julien 29 oct.  17  2015 ltsugar.m4 -> /usr/share/aclocal/ltsugar.m4
lrwxrwxrwx 1 julien julien 31 oct.  17  2015 ltversion.m4 -> /usr/share/aclocal/ltversion.m4

On my current build host I don't have libtool installed, that's how I got to this one.
> 
> > +
> > +# Ensure the libtool version is updated,
> 
> Why?
> 
Well if the m4 script it points to are unknown I don't see how we can
live without updating it.

> > +# also make _CONF_ENV works instead of _CONF_OPTS for endiannes
> 
> I don't see what this means. _CONF_ENV works regardless of whether
> AUTORECONF is YES or NO.
> 
It means that I don't know how was the original config script generated,
but it whould not honor it's environment. running autoreconf fixes it.

> > +DIEHARDER_AUTORECONF = YES
> > +
> > +# fix endiannes detection
> 
> endianness with two 's' at the end, see
> https://en.wikipedia.org/wiki/Endianness.
> 
Ok sorry for that one.

Best Regards,

Julien VdG

> Thanks!
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


More information about the buildroot mailing list