Build failure with dbi enabled

[John Ralls]

> 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/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 ?

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 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.

Regards,
John Ralls