Build failure with dbi enabled

[Geert Janssens]

On Friday 24 April 2015 14:29:39 John Ralls wrote:
> > On Apr 24, 2015, at 8:54 AM, Geert Janssens
> > <geert.gnucash at kobaltwit.be> wrote:> 
> > 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/configu
> >>> re
> >>> 
> >>> : line 22003: LD_LIBRARY_PATH: command not found
> >>> 
> >>> /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/configu
> >>> re
> >>> 
> >>> : 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 ?
> OSX's bash just ignores the first problem:
>   configure:23024: checking for dbi/dbi.h
>   configure:23024: result: yes
>   configure:23069: Search Path
>   configure:23071: checking Looking for at least one supported DBD
> module

That snippet appears to come from config.log which indeed doesn't print the bash error 
message. The error message is printed on stderr, which I happened to see because configure 
stops right after it due to the real error below.

> > 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.
> 
> I just looked at the history of that, and I changed it in 1d6fd557:
> -      export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$EXTRA_SEARCH_LIBS"
> -      AC_MSG_CHECKING([Looking for at least one supported DBD
> module]) -      AC_RUN_IFELSE([AC_LANG_PROGRAM([$LDINC],
> +    old_ld_library_path="$LD_LIBRARY_PATH"
> +    LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$EXTRA_SEARCH_LIBS"
> +    AC_MSG_NOTICE([Search Path $(LD_LIBRARY_PATH)])
> +    AC_MSG_CHECKING([Looking for at least one supported DBD module])
> +    AC_RUN_IFELSE([AC_LANG_PROGRAM([$LDINC],
> 
> which answers the "why didn't it fail for you before" question. I can
> only guess that Mac and MinGW are using a different process model so
> that the test executables run in configure's environment rather than
> a new one.

Doh. I had looked up that commit as well to check where the AC_MSG_CHECKING came from 
(which printed the shell errors), but I failed to notice the export command had been dropped...