Use symbol versioning

[reddwarf69]

It should be adapted to whatever symbols are exported in the next release.

It avoid crashes if, for some reason, a process (indirectly) ends with both libmlt5.so and libmlt6.so in its image.
It also lets RPM automatically add the minimum required version for dependent packages. So, if kdenlive uses a symbol added in MLT 0.9.0 RPM will specify MLT >= 0.9.0 as a dependency. Even if kdenlive is actually compiled using MLT 0.9.2.

But it requires discipline. In the future, every new symbol exported must be added to the version script file.

[ddennedy]

RE: It avoid crashes if, for some reason, a process (indirectly) ends with both libmlt5.so and libmlt6.so in its image.
I want to understand this better. Can this really only happen, for example, if a plugin/module is compiled for some other version of libmlt?

RE: every new symbol exported must be added to the version script file.
Eww, how is mlt++.vers generated? What is the process for maintaining it? If I have to use nm and manually maintain this, I am not very inclined to adopt it. Can some build frameworks like cmake automate this?

[reddwarf69]

Since the number of applications using mlt is quite low the crash problem is quite controlled. But the situation would be:

• kdenlive is compiled against libmlt.so.5 and libA, libA is compiled against libmlt.so.6. Now if libA is loaded before libmlt.so.5, when kdenlive wants to call mlt_frame_clone() it will not use the version from libmlt.so.5 but the one from libmlt.so.6. In more used libraries this situation has resulted in crashes (gstreamer with the transition to 1.0 right now is quite problematic). As with GStreamer, generally people don't care until the problem appears, but by then it's usually too late to do it properly.
• With MLT plugins it could happen if for example someone creates a frei0r plugin which uses MLT. Again, if the application and the frei0r plugins use incompatible versions of MLT -> crash.

About the second point, symbols versioning and C++ is actually an ugly combination. I created it by hand, but it could actually be automated. I could try to do it... whenever I have time ("this month"?).

[ddennedy]

Is the C++ symbol sensitive to the g++ version and perhaps clang++ has a different scheme? I did not have a problem with it until I saw the mlt++ block of symbols!

[reddwarf69]

g++ changed it in version 3.4 to use the "Itanium C++ ABI", which appears to be the standard in the ELF world (Microsoft has its own scheme). I don't know 100% for sure about clang++, I never used it. But a quick search returns http://clang.llvm.org/doxygen/ItaniumMangle_8cpp_source.html, so at the very least clang++ supports the same symbol name mangling scheme. I guess it's the default in ELF systems.

[reddwarf69]

I changed it to explicitly specify every symbol. This way no new symbols will be added to an old version by accident.
I also use unmangled symbols for the C++ RTTI and virtual method table, which I guess you will prefer.

[reddwarf69]

One thing that perhaps wasn't 100% clear. When an app is linked against libmlt now those "MLT_0.8.8" and "MLTPP_0.8.8" strings are also saved in the app binary. So they can not change. They start to form part of the library interface.

Meaning that you may want to change the 0.8.8 part for 0.9.0, or whatever the next release number is going to be, as soon as possible. Otherwise apps compiled with the current GIT version will stop working with the next release.
Alternatively you can just leave it as it is. There is nothing technically wrong with the 0.9.0 release using the string "MLTPP_0.8.8" for its symbols. Just that it's confusing for a human reader.