Build failure with dbi enabled
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 ? Thanks, Geert diff --git a/configure.ac b/configure.ac index fc4fb20..c8c53c7 100644 --- a/configure.ac +++ b/configure.ac @@ -648,8 +648,8 @@ then ;; esac old_ld_library_path=$LD_LIBRARY_PATH -LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$EXTRA_SEARCH_LIBS -AC_MSG_NOTICE([Search Path $(LD_LIBRARY_PATH)]) +export 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], [[if (!$lt_cv_dlopen(libdbdsqlite3.$LDEXT$LDFUNCARGS)) return -1; @@ -677,7 +677,7 @@ to the configure argument list and run it again. LIBDBI_LIBS=-ldbi _COMPONENTS=$_COMPONENTS dbi LIBS=$saved_libs -LD_LIBRARY_PATH=$old_ld_library_path +export LD_LIBRARY_PATH=$old_ld_library_path else AC_MSG_ERROR([ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Build failure with dbi enabled
On Apr 24, 2015, at 6:36 AM, Geert Janssens geert.gnuc...@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? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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.gnuc...@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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Build failure with dbi enabled
On Apr 24, 2015, at 8:54 AM, Geert Janssens geert.gnuc...@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.gnuc...@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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Build failure with dbi enabled
Geert, -- Forwarded message -- From: Geert Janssens geert.gnuc...@kobaltwit.be To: gnucash-devel@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.gnuc...@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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
