Hi,

Between 6.11 and 6.15, bobcat removed the out-of-line special member
functions of FBB::Pattern. In 6.11 these were defined in
pattern/destructor.cc,
destroy.cc, etc.; in 6.15 the class no longer declares them, so they are
implicitly generated in each user. The library soname is still
libbobcat.so.6,
so binaries built against the older headers still reference the old symbols,
and some of those are no longer exported by libbobcat.so.6.15.01.

In total, 37 dynamic symbols exported by 6.11.00 are gone in 6.15.01,
among them:

   FBB::Pattern::Pattern(FBB::Pattern&&)
   FBB::Pattern::operator=(FBB::Pattern&&)
   FBB::Pattern::operator=(FBB::Pattern const&)
   FBB::Pattern::copy(FBB::Pattern const&)
   FBB::Pattern::destroy()

Impact in unstable/forky: filtermail 1.07.01-1 (built in April against an
older libbobcat-dev) is linked with BIND_NOW and does not start with
libbobcat6 6.15.01-1:

   $ filtermail --help
   filtermail: symbol lookup error: filtermail: undefined symbol:
_ZN3FBB7PatternaSEOS0_

(_ZN3FBB7PatternaSEOS0_ = FBB::Pattern::operator=(FBB::Pattern&&))

I checked the other packages linking libbobcat6 in unstable (bisonc++,
flexc++,
gpg-remailer, guncat, multispeech, natlog, oxref, simrisc, ssh-cron,
stealth,
xd). Against the Debian 6.15.01-1 library they currently only need weak
references or symbols that are still exported, so filtermail is the only
binary I found failing. That is partly luck: FBB::Pattern::~Pattern() is no
longer defined in the 6.15 sources but is still exported by the Debian
build.
In Ubuntu, which builds with -flto=auto, ~Pattern() is not exported, and
flexc++, bisonc++, gpg-remailer, oxref and stealth also fail with
"undefined symbol: _ZN3FBB7PatternD1Ev".

A no-change rebuild of filtermail (and flexc++) against libbobcat-dev
6.15.01-1
fixes this: the rebuilt binaries no longer reference those symbols and
run fine.

Possible fixes:
  - bump the soname (libbobcat7) for this ABI change, or
  - binNMU the reverse dependencies (at least filtermail) and add
    Breaks: filtermail (<< 1.07.01-1+b1) (and the others if needed) to
    libbobcat6, so that old binaries cannot be combined with 6.15.
A symbols file for libbobcat6 would help catch such changes in the future.

Thanks,

Hello Sebastian,

Thank for the detailed bug report.  I will work with the upstream author
to add the symbols file and the binNMU.

Thank you,
tony

Dear Tony Mancill, you wrote:
And, Sebastian, of course, also thank you from my side :-)

Indeed, you're right: the mentioned Pattern members aren't mentioned in the
recent bobcat version. Mainly because in bobcat 6.13.00 a segfault when using
static Pattern objects was fixed, and the Pattern members you mentioned

are, because of that, available by default. E.g., the following program runs
OK and shows 'matched' twice:

    #include <iostream>
    #include <string>

    #include <bobcat/pattern>

    using namespace std;
    using namespace FBB;

    int main(int argc, char **argv)
    {
        Pattern hello("^hello");

        Pattern hello2;
        hello2 = hello;

        Pattern hello3{ move(hello) };
        Pattern hello4;
        hello4 = move(hello2);

        string hw{"hello world"};

        if (hello3 << hw)
            cout << "matched\n";

        if (hello4 << hw)
            cout << "matched\n";
    }

Also, valgrind reports:

    ==2899== HEAP SUMMARY:
    ==2899==     in use at exit: 0 bytes in 0 blocks
    ==2899==   total heap usage: 130 allocs, 130 frees, 93,524 bytes allocated
    ==2899==
    ==2899== All heap blocks were freed -- no leaks are possible
    ==2899==
    ==2899== For lists of detected and suppressed errors, rerun with: -s
    ==2899== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

But what's clearly wrong is that the required version of libbobcat-dev in
filtermail's control file is still at 6.11.00:

    Build-Depends: ...
                   libbobcat-dev (>= 6.11.00),
                   ...

So I propose to update libbobcat-dev's version in filtermail's control file
instead of adding members that are already available by default in libbobcat's
version 6.15.01. Software using bobcat's Pattern class might need
recompilation when linking to 6.15.01 and should, after that, work as before.

And, of course, an new bobcat version (6.15.01) can then add the symbols file.

Is that an option?

Hi Frank, Tony,

Thanks for the quick replies.

Frank, you're right that code compiled against the 6.15 headers works,
since those members are now generated inline. The problem is binaries
that were already built against 6.11 headers, like filtermail
1.07.01-1 currently in unstable: they still reference the out-of-line
symbols, and 6.15 no longer exports them, so they fail at startup.

Bumping filtermail's Build-Depends alone won't fix that. It only takes
effect when filtermail is rebuilt, and even then nothing stops apt from
upgrading libbobcat6 while keeping an old filtermail binary.

I think what's needed is:
 - binNMUs of the libbobcat6 reverse dependencies against 6.15.01
   (at least filtermail; the others only work today because
   ~Pattern() happens to still be exported, and with -flto=auto, as
   in Ubuntu, flexc++, bisonc++, gpg-remailer, oxref and stealth
   break too)
 - Breaks: on the pre-binNMU versions in libbobcat6, e.g.
   filtermail (<< 1.07.01-1+b1)
 - the symbols file in the same upload, to catch this in the future

(A soname bump would also work, if you prefer that route.)

Thanks,
Sebastien