[Matroska-devel] [Patches] Portability, support for CloudABI, etc.

Moritz Bunkus moritz at bunkus.org
Tue Nov 24 22:11:59 CET 2015


Hey,

> I have to confess I'm not a C++ ABI expert,

Neither am I :)

> but how does adding an additional constructor break the ABI? Adding
> additional virtual functions will break its vtable, but as far as I
> know, adding an extra constructor would do nothing in addition to
> exporting another symbol, right?

You may be quite right. My usual reference is KDE's wiki article[1] on
this topic. As for our case it's not 100% clear. On the one hand it
states that you can "add new non-virtual functions including signals and
slots and constructors". But it also states that you cannot "add an
overload (BC, but not SC: makes &func ambiguous), adding overloads to
already overloaded functions is ok (any use of &func already needed a
cast)" for "existing functions of any type".

The new constructor is an overload, and I would say that the second part
applies to our case. But I'm definitely not knowledgeable enough to
decide this with confidence.

> But it looks as if nothing like that was ever added. Packages like
> GNOME's glib still generate their glibconfig.h header file manually
> (~200 lines of m4/shell scripting).

Hmm, for us a very simple solution would suffice, wouldn't it? We only
have to add the following shell code to configure after the detection of
fopen:

# Create new/truncate ebml_config.h
echo > ebml_config.h

if test x"$ac_cv_" = xyes; then
  echo '#define LIBEBML_HAVE_FOPEN 1' >> ebml_config.h
else
  echo '// fopen() is not available.' >> ebml_config.h
  echo '// #define LIBEBML_HAVE_FOPEN 1' >> ebml_config.h
fi

Then ship that generated ebml_config.h. It doesn't have to be anything
fancy with m4.

Do you see any real problems except it being somewhat hackish?

> To be honest, I don't think it's worth investing that amount of effort
> in this case. We coulkd consider just adding the following to the
> existing EbmlConfig.h:
>
> #ifndef __CloudABI__
> #define LIBEBML_HAVE_FOPEN
> #endif

I don't really like such magical #defines and would really prefer a
configure-based solution.

Kind regards,
mosu

[1] https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20151124/4480b707/attachment.sig>


More information about the Matroska-devel mailing list