Problem building master with autotools

John Ralls jralls at
Tue Jul 11 23:19:04 EDT 2017

> On Jul 11, 2017, at 10:13 AM, Alex Aycinena <alex.aycinena at> wrote:
> John,
> ---------- Forwarded message ----------
> From: John Ralls <jralls at <mailto:jralls at>>
> To: Geert Janssens <geert.gnucash at <mailto:geert.gnucash at>>
> Cc: gnucash-devel at <mailto:gnucash-devel at>, Alex Aycinena <alex.aycinena at <mailto:alex.aycinena at>>
> Bcc: 
> Date: Tue, 11 Jul 2017 06:57:52 -0700
> Subject: Re: Problem building master with autotools
> > On Jul 11, 2017, at 5:33 AM, Geert Janssens <geert.gnucash at <mailto:geert.gnucash at>> wrote:
> >
> > On dinsdag 11 juli 2017 03:38:16 CEST Alex Aycinena wrote:
> >> With a fresh checkout of master, I try to build with the autotools but I
> >> get an error in linking test-import-pending-matches with test-engine-stuff
> >> during make as follows:
> >>
> >> /usr/bin/ld:
> >> ../../../src/engine/test-core/.libs/libgncmod-test-engine.a(test-engine-stuf
> >> f.o): undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
> >> /usr/lib64/ error adding symbols: DSO missing from command
> >> line
> >> collect2: error: ld returned 1 exit status
> >> Makefile:837: recipe for target 'test-import-pending-matches' failed
> >>
> >> I can build with cmake but I would like to run make check after an
> >> autotools make because I think it runs different checks.
> >>
> >> Can anyone give me an idea of how to get this to work? This is Fedora 25.
> >>
> >
> > Odd I don't get this on my system (Fedora 25 as well).
> >
> > The linker is having issues resolving "__gxx_personality_v0". The internet
> > cites two common issues for this:
> > - either a library is missing
> > - or the sequence of libraries on the command line is wrong (a symbol to
> > resolve should appear after the source in which it's being imported).
> I hit that the other day and the problem was that I had installed libraries from master while trying to build maint. Since the latter doesn’t link to libstdc++, picking up one of the installed libraries that needed it caused the error and clearing out the installed libgnc* fixed the problem.
> Regards,
> John Ralls
> Ah, so it is not just me. This might help me solve it but I'm not quite following. If I do a new checkout and then build in an empty separate build directory, wouldn't that avoid the problem? Where would the installed libgnc* be that causes the problem that I would have to clear out? In /usr/lib64/gnucash? If I change anything there, wouldn't that mess up the Fedora installed gnucash package?
> By the way, I'm getting the same problem on three separate systems: a Fedora 24, a Fedora 25 and a Fedora 25 VM, so if it is some strange system configuration I have, then I have it on three systems, not just one. I think I'll try a new VM of Fedora 26 that just came out and see if it works there.


You don’t necessarily have the same problem just because you have the same symptom, but no, just having a separate build directory isn’t enough. If you have libgnc* anywhere the linker looks for libraries you run the risk of it linking one of those instead of the ones in your build-dir. The most likely suspect would be the components of the GnuCash in /usr/lib that you use for keeping your books, but if you set —prefix=/opt/foo and run make install, then later have another build for which you also set —prefix=/opt/foo then the installed libraries from the first build can screw up the second.

Short of switching to a Mac, where the application bundles and separate jhbuild prefixes keep everything perfectly isolated, the best solution is to develop in a VM and if you have multiple builds ensure that they each have their own prefix directory so that none can see the product of another.

John Ralls

More information about the gnucash-devel mailing list