On Friday 24 April 2015 14:29:39 John Ralls wrote: > > On Apr 24, 2015, at 8:54 AM, Geert Janssens > > <[email protected]> wrote:> > > On Friday 24 April 2015 07:31:02 John Ralls wrote: > >>> On Apr 24, 2015, at 6:36 AM, Geert Janssens > >>> <[email protected]> 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... _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
