[lsb-discuss] unoffficial LSB conference call minutes for 24 Apr 2013

Jeff Licquia licquia at linuxfoundation.org
Wed Apr 24 22:42:14 UTC 2013

On 04/24/2013 01:49 PM, Denis Silakov wrote:
> Unfortunately I was not able to attend, could somebody give more details
> about problems you see with C++, virtual tables and database?

Sure; Russ was paraphrasing comments I made regarding libchk.

At one time, libchk was very naive about handling vtable changes.  This
was fixed in the context of LSB 4.0, a fact that I had forgotten when
bringing up the C++ updates on the docket for LSB 5.0.  (See bug 1796
for the full scoop.)

There is an issue with vtables that appears to have crept in, which was
causing the build failures on newer distros.  Apparently, gcc/binutils
now expects that the actual implementation in the .so matches the
headers; in particular, if one overrides an inline virtual function in a
header, gcc generates code that expects the actual override to exist in
the link library.  This is a problem if your .so files bear no
relationship to your headers, as ours do.

This led to an observation that problems of this nature would go away
with proper C++ header generation, which we can't do at the moment.

I speculated that getting to the point where we can generate headers
might require database schema fixes.  If I understand correctly, you're
saying that this should not be necessary, which is good news.  I imagine
that actually implementing C++ header generation would uncover needed
tweaks, but that should be far less intrusive.

So I think we're in sync with this statement:

> The second part of data is 'nice to have', but not obligatory. Imho,
> during uplift for 5.0, it's ok to not go beyond the set of symbols.
> Especially keeping in mind that populating db with class-related data is
> not easy, we currently don't have a tool to automate this task and we
> are very limited in resources.
> So my suggestion is to just add new symbols and leave vtables for better
> times.

...with the added observation that I've poked at the problem of
automated tools a little, with what look like encouraging results.  As I
understand it, the biggest problem with C++ tools is that C++ is hugely
difficult to parse.  Other tools for things like refactoring have had
success with the Elkhound/ELSA parser doing some pretty complex stuff,
so that might be an avenue of attack.
Jeff Licquia
The Linux Foundation
+1 (317) 915-7441
licquia at linuxfoundation.org

Linux Foundation Events Schedule:  events.linuxfoundation.org
Linux Foundation Training Schedule: training.linuxfoundation.org

More information about the lsb-discuss mailing list