[Matroska-devel] libebml & libmatroska as DLLs

Moritz Bunkus moritz at bunkus.org
Sat Jan 10 15:44:11 CET 2004


Heya,

I've committed changes to libebml and libmatroska which allow building
both as DLLs. This i controlled by defining a couple of magic words. So
if they aren't defined static libraries will be built - so nothing
changes for devels.

Here's how it is: If libebml should be built as a DLL then during the
DLL build process 'EBML_DLL_EXPORT' has to be defined. An application
using the DLL has to define 'EBML_DLL'.

If libmatroska should be build as a DLL then during the DLL build
process 'MATROSKA_DLL_EXPORT' has to be defined. An application using
the DLL has to define 'MATROSKA_DLL'. As libmatroska depends on libebml
you also have to define 'EBML_DLL'.

So apps using both libs as DLLs have to define both 'EBML_DLL' and
'MATROSKA_DLL'.

If both libs should be built statically nothing has to be defined.

For details see libebml/ebml/EbmlConfig.h,
libebml/make/mingw32/Makefile, libmatroska/matroska/KaxConfig.h and
libmatroska/make/mingw32/Makefile.

The reason for all these defines is that it seems to be impossible on
Windows to do it otherwise. You can't use '__declspec(dllimport)' on
statically build libs... I've checked other libraries (expat and
wxWindows) and both also use such a system (for expat you have to define
XML_STATIC for a static version..., similar for wxWindows which is more
like my system). I honestly despise Windows for such a system because
you don't need ANY of this crap on most Unix systems...

Please test if the code still compiles with MS VC.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds



More information about the Matroska-devel mailing list