Dmitry, was this in one of your build scripts? If so, is the log available on the web?

Probably doesn't matter, but stable, testing, or unstable?

Hm, there is not much of "my build script" - mostly it is an invocation of CMake in clean build environment.

The suite is "unstable" of course as it is the default suite for upload. 

I tried to build in "stable" and got the same result.

There is no downloadable log (as I could not upload because of this problem) but I shall be happy to attach full build log here if it helps.

Created attachment 373637 [details]
log: build in "unstable"

Geert,

Can you look at this when you get up and ideally before I do? The problem seems to be that setting PREFIX=/usr and SYSCONFDIR=/etc, as a distro would normally do, turns off binreloc (intended) and either breaks get_build_prefix or causes it to return NULL so the 

Here's the binreloc warning:
CMake Warning at CMakeLists.txt:84 (message):
  /etc is set outside of the intallation prefix /usr.  That will break
  relocation so ENABLE_BINRELOC is set to off.  With relocation disabled
  GnuCash will run only in its configured install location.  You must set
  GNC_UNINSTALLED=1 and GNC_BUILDDIR=/path/to/builddir to run from the build
  directory.  GnuCash will not run from a DESTDIR.

and the rest of the test output from LastTest.log:
Command: "/usr/bin/cmake" "-E" "env" "GNC_UNINSTALLED=YES;GNC_BUILDDIR=/build/gn
ucash-3.9/.build;GNC_UNINSTALLED=yes" "/build/gnucash-3.9/.build/bin/test-gnc-pa
th-util"
Directory: /build/gnucash-3.9/.build/libgnucash/core-utils/test
"test-gnc-path-util" start time: Apr 10 23:49 UTC
Output:
----------------------------------------------------------
Running main() from /build/gnucash-3.9/.build/__gtest/googletest/src/gtest_main.
cc
[==========] Running 5 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 5 tests from PathTest
[ RUN      ] PathTest.gnc_path_get_prefix
[       OK ] PathTest.gnc_path_get_prefix (0 ms)
[ RUN      ] PathTest.gnc_path_get_bindir
[       OK ] PathTest.gnc_path_get_bindir (0 ms)
[ RUN      ] PathTest.gnc_path_get_libdir
[       OK ] PathTest.gnc_path_get_libdir (0 ms)
[ RUN      ] PathTest.gnc_path_get_datadir
[       OK ] PathTest.gnc_path_get_datadir (0 ms)
[ RUN      ] PathTest.gnc_path_get_sysconfdir
/build/gnucash-3.9/libgnucash/core-utils/test/gtest-path-utilities.cpp:117: Failure
Expected equality of these values:
  gnc_path_get_pkgsysconfdir()
    Which is: "/etc/gnucash"
  sysconfpath
    Which is: "/build/gnucash-3.9/.build/libgnucash/core-utils/test/etc/gnucash"

[  FAILED  ] PathTest.gnc_path_get_sysconfdir (0 ms)

> Can you look at this when you get up and ideally before I do? 

I'm not sure I can make assumptions regarding your time zone...
I'm in Sydney and I'm still up. ;)

I'm not sure what you are asking me to check. Yes, it is probable that CMAKE is getting PREFIX set. I don't know if I can switch that off. 

The only arguments that I set for the build system explicitly are the following:

~~~~
  -Wdev \
  -DCMAKE_VERBOSE_MAKEFILE=ON  \
  -DCMAKE_BUILD_TYPE=Release   \
  -DCMAKE_CXX_FLAGS="$(CXXFLAGS) $(CPPFLAGS)" \
  -DWITH_PYTHON=ON             \
  -DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/gnucash \
  $(CMAKE_WORDS_BIGENDIAN) \
;
~~~~

3.8b builds successfully in the very environment where 3.9 fails.
I can't quite pinpoint the problem but it looks like regression to me.

Dimitry, comment 4 was directed to my colleague Geert Janssens, not to you. Unfortunately it would seem he wasn't able to look at it, so getting this fixed for the immenent 3.10 snap release is unlikely.

Dmitry, it is a regression, probably caused by https://github.com/Gnucash/gnucash/commit/4537c1de365880fe89554289c3e2f43edeff53de. That was a fix for bug 794916 a different sysconfigpath wrinkle, when prefix is /opt. Geert wrote that and that's why I asked him to look at this.

The entire cmake command-line from your build log is
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_AUTOGEN_VERBOSE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -Wdev -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=Release "-DCMAKE_CXX_FLAGS=-g -O2 
-fdebug-prefix-map=/build/gnucash-3.9=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-error=stringop-truncation -Wdate-time 
-D_FORTIFY_SOURCE=2" -DWITH_PYTHON=ON 
-DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/gnucash 
-DCMAKE_SYSCONFDIR=/etc

Totally unrelated to this: You probably want to do the same for CMAKE_C_FLAGS as for CMAKE_CXX_FLAGS. GnuCash has a lot more C than C++. Setting CMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/gnucash means that the shared libraries (linked at startup) go there and the loadable modules (dlopened later, though not much later) go to /usr/lib/x86_64-linux-gnu/gnucash/gnucash. Is that what you want?

Found it. The changes to deal with directories like SYSCONFDIR being outside of PREFIX failed to take account of the GNC_UNINSTALLED case. It will be fixed in 3.10, which I will now proceed to release.

Many thanks for fixing the problem so fast, John. Much appreciated.

I've just tried to build 3.10 but if failed as follows:

~~~~
make -f bindings/python/tests/CMakeFiles/test-python-bindings.dir/build.make bindings/python/tests/CMakeFiles/test-python-bindings.dir/build 
make[3] Entering directory '/build/gnucash-3.10/.build' 
make[3] *** No rule to make target '../bindings/python/tests/swig-app-utils-python', needed by 'bindings/python/tests/CMakeFiles/test-python-bindings'.  Stop.                                                                                                                                                            
make[3] Leaving directory '/build/gnucash-3.10/.build' 
make[2] *** [CMakeFiles/Makefile2:11497: bindings/python/tests/CMakeFiles/test-python-bindings.dir/all] Error 2 
~~~~

As for CMAKE_C_FLAGS, I think we had to pass CMAKE_CXX_FLAGS to preserve hardening flags that were lost or not picked up from the environment. Apparently CMAKE_C_FLAGS have no such problem, I think, but perhaps it might be worth re-checking as custom flags optiopn was introduced a while ago around the time when build system was changed to CMake...

I did not answer your question regarding "CMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/gnucash" -- that is indeed intended. This is required for Debian policy compliance so private libraries and plugins are segregated from shared libraries location.

(In reply to John Ralls from comment #4)
> Geert,
> 
> Can you look at this when you get up and ideally before I do? 

John, I have been afk for the last two days. Sorry I couldn't respond. And I'm glad you found it yourself.

> This is required for Debian policy compliance so private libraries and plugins are segregated from shared libraries location.

OK, with the stipulation that here "shared libraries" has a different meaning from it's usual "dynamically linked libraries". Instead it means "libraries intended for use by other programs". "Public libraries" might be a better wording.

WRT CPPFLAGS, that's an autotools thing. It's intended for flags to apply to all C flavors, so automake will add it along with CFLAGS to C compile commands, along with CXXFLAGS to C++ compiles, and with OBJCFLAGS for an objective-c compile. Cmake will look for CFLAGS, CXXFLAGS, and OBJCFLAGS in the environment and set the corresponding CMAKE_C_FLAGS, etc. from them but it ignores CPPFLAGS. If you're passing -D_FORTIFY_SOURCE=2 in CFLAGS too then all is well, but if not then you need to add CPPFLAGS to CMAKE_C_FLAGS the same way you do for CMAKE_CXX_FLAGS.