Re: [PATCH 4/9] build: update AC_PACKAGE_WANT_GDBM() and src/dbtest.c to build

[Eryu Guan]

On Thu, Dec 14, 2017 at 06:55:03PM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 14, 2017 at 01:51:02PM +0800, Eryu Guan wrote:
> > On Tue, Dec 12, 2017 at 04:45:14PM -0800, Luis R. Rodriguez wrote:
> > > Modern gdbm-devel packages bundle together gdbm.h and ndbm.h.
> > > The old m4 macro had detection support for some old gdbm libraries
> > > but not for new ones.
> > > 
> > > We fix compilation of src/dbtest.c by making the autoconf helper
> > > check for this new arrangement:
> > > 
> > > If both gdbm.h and gdbm.h are found define set both gdbm_ndbm_=true,
> >                      ^^^^^^ ndbm.h?
> > > and have_db=true, and define HAVE_GDBM_H. The src/dbtest.c already
> > > had a HAVE_GDBM_H but there was never a respective autoconf settter for
> > > it. We can just re-use this and fix it for new arrangement.
> > > 
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxx>
> > 
> > This looks fine to me.
> > 
> > The only system I have by hand that have both <gdbm.h> and <ndbm.h> but
> > not any <gdbm/[gn]dbm.h> is openSUSE Tumbleweed.
> 
> Indeed, openSUSE and SLE releases.
> 
> > Without this patch,
> > dbtest was not built on openSUSE, and was built successfully with this
> > patch applied.
> 
> Yeap.
> 
> > And dbtest is still built on RHEL6/7 and Fedora.
> 
> Feel free to modify the commit log accordingly then. Curious, what packages
> does Fedora/ RHEL6/7 use for the requirement here?
> 
> We just have one:
> 
> $ rpm -ql gdbm-devel-1.12-1.282.x86_64
> /usr/bin/gdbm_dump
> /usr/bin/gdbm_load
> /usr/bin/gdbmtool
> /usr/include/dbm.h
> /usr/include/gdbm.h
> /usr/include/ndbm.h
> /usr/lib64/libgdbm.a
> /usr/lib64/libgdbm.so
> /usr/lib64/libgdbm_compat.a
> /usr/lib64/libgdbm_compat.so
> /usr/lib64/libndbm.a
> /usr/lib64/libndbm.so
> /usr/share/info/gdbm.info.gz
> /usr/share/man/man1/gdbm_dump.1.gz
> /usr/share/man/man1/gdbm_load.1.gz
> /usr/share/man/man1/gdbmtool.1.gz
> /usr/share/man/man3/gdbm.3.gz

gdbm-devel too, but it has gdbm/[gn]dbm.h pointing to ../[gn]dbm.h, so
there's no such problem and dbtest is building normally.

# rpm -ql gdbm-devel
/usr/include/dbm.h
/usr/include/gdbm
/usr/include/gdbm.h
/usr/include/gdbm/dbm.h
/usr/include/gdbm/gdbm.h
/usr/include/gdbm/ndbm.h
/usr/include/ndbm.h
/usr/lib64/libgdbm.so
/usr/lib64/libgdbm_compat.so
/usr/share/info/gdbm.info.gz
/usr/share/man/man3/gdbm.3.gz

> 
> > BTW, I'll queue patch 3 and this patch for next fstests release, while
> > other patches seem not necessary,
> 
> I think patch 2 is fine too.
> 
> > I agreed with Dave that groups are not
> > for excluding tests, the required tools and environments should be
> > detected by tests and _notrun if not met.
> 
> Yeah makes sense now. I think we should also document when adding
> a group makes sense as well.
> 
> > (The README change looks fine,
> > but it doesn't apply due to the "fsgqa-381" change, so I drop it too for
> > now.)
> 
> Feel free to modify it, its not a big deal.

OK, I'll modify on commit, thanks!

Thanks,
Eryu