> 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/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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
