Build failure with dbi enabled

Alex Aycinena alex.aycinena at gmail.com
Fri Apr 24 17:35:51 EDT 2015


Geert,


> ---------- Forwarded message ----------
> From: Geert Janssens <geert.gnucash at kobaltwit.be>
> To: gnucash-devel at gnucash.org
> Cc:
> Date: Fri, 24 Apr 2015 17:54:02 +0200
> Subject: Re: Build failure with dbi enabled
> On Friday 24 April 2015 07:31:02 John Ralls wrote:
> > > On Apr 24, 2015, at 6:36 AM, Geert Janssens
> > > <geert.gnucash at kobaltwit.be> wrote:
> > >
> > > I upgraded to Fedora 21 a couple of days ago and today I reran a
> > > gnucash build for the first time since that upgrade.
> > >
> > > As the upgrade changes lots of libraries I decided to start clean.
> > > That is, remove build directory and start with a call to
> > > autogen.sh.
> > >
> > > The call to autogen.sh triggers the same subdir-objects warnings
> > > Alex already reported earlier. I'm conveniently ignoring them for
> > > now. The related bug will apparently be fixed in automake 1.16 (not
> > > yet in Fedora 21).
> > >
> > > However when I ran configure (from a clean build directory), it
> > > exited with this error: ...
> > > checking for dbi/dbi.h... yes
> > > /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/configure
> > > : line 22003: LD_LIBRARY_PATH: command not found
> > > /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/configure
> > > : line 22004: LD_LIBRARY_PATH: command not found
> > > configure: Search Path
> > > checking Looking for at least one supported DBD module... configure:
> > > error: Unable to find any of the supported dbd modules
> > > (libdbdsqlite3, libdbdmysql, or libdbdpgsql) needed to actually use
> > > the SQL backend. ...
> > >
> > > I fixed this by changing
> > > AC_MSG_NOTICE([Search Path $(LD_LIBRARY_PATH)])
> > > to
> > > AC_MSG_NOTICE([Search Path $LD_LIBRARY_PATH])
> > > in configure.ac
> > >
> > > I'm surprised this wasn't detected before. Is this new behavior of
> > > the automake tools ?
> > >
> > >
> > > The next configure run exited again due to no DBD modules being
> > > found even though the "LD_LIBRARY_PATH: command not found" errors
> > > were now gone:
> > > ...
> > > checking for dbi/dbi.h... yes
> > > configure: Search Path :/usr/lib64/dbd
> > > checking Looking for at least one supported DBD module... configure:
> > > error: Unable to find any of the supported dbd modules
> > > (libdbdsqlite3, libdbdmysql, or libdbdpgsql) needed to actually use
> > > the SQL backend. ...
> > >
> > > Looking at config.log it seems to me the LD_LIBRARY_PATH should be
> > > exported before running the dbi driver tests. On my system, I can
> > > make configure work by applying the attached patch.
> > >
> > > Before committing it however, I'd like some feedback on how it
> > > behaves on OS X. John, can you look at this patch ?
> >
> > Geert,
> >
> > The patch should be harmless. I think it odd that only that one
> > environment variable needs to be exported and to have its brackets
> > removed.
> >
> > I wonder, though, if this is really due to a change in autotools. Are
> > you able to compare a configure made with F20 to the one made with
> > F21?
> >
> My initial message may have been misleading. I tested on another machine
> still running F20
> and I hit the exact same errors. So this is clearly not a autotools
> change. I'm actually surprised
> you don't see these errors on your OSX build because
> $(LD_LIBRARY_PATH) is shell syntax for "execute the command named
> LD_LIBRARY_PATH".
>
> I'm aware configure.ac is not really shell but a macro language with
> snippets of shell code
> intermingled. On my system at least the
> $(LD_LIBRARY_PATH) construct is not interpreted by autotools and is left
> in the remaining
> configure shell script unmodified. Hence the errors when configure is run.
>
> I have also looked in the most recent build logs on our Windows build
> server. These errors pop
> up there as well, but don't appear to be fatal there. Maybe that's the
> same on your OS X build ?
>
> That probably justifies the first part of my patch (ie removing the
> parenthesis around
> LD_LIBRARY_PATH).
>
> More interesting now it figuring out why my build depends on
> LD_LIBRARY_PATH being
> exported while the OS X and Windows builds don't.
>
> Geert
>

Just to confirm that I have been having this problem also, showing up all
of a sudden, for a week or so on both F20 & F21. Since I am focusing on
other gnucash work I just worked around it by using the no dbi config
switch.

Alex


More information about the gnucash-devel mailing list