[Bug 537363] Review Request: lv2-c++-tools - Support library for writing LV2 plugins in C++

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=537363

--- Comment #7 from Orcan 'oget' Ogetbil <oget.fedora at gmail.com> 2010-02-20 05:19:54 EST ---
Hi, I got a hold of the project developer and he requested me to leave the two
libraries static, as otherwise things might break. Here is what he says:

> Well, I don't think I'll ever make the libraries shared by default -
> there are reasons for having them static other than ABI instability. I
> don't think that the gain in file size and maintainability in separating
> such a tiny piece of code (two 2-line functions and one 3-line function
> for liblv2-plugin.a, one 2-line function and one 4-line function for
> liblv2-gui.a) justifies the additional annoyance of having an extra
> runtime dependency for every plugin built using the libraries (more of
> an annoyance for people who build from source than for those who use
> package managers obviously).
>
> Also, when looking at the code I remembered a reason why it's not a good
> idea to build the current code as shared libraries. liblv2-plugin.a
> contains a symbol, LV2::get_lv2_descriptors()::descriptors, which is a
> list of plugin descriptors for all the plugins in that plugin library.
> If liblv2-plugin is shared that symbol would be shared by all plugin
> libraries that a host has loaded, which would cause two problems:
>
> 1) Since all the plugin descriptors would end up in the same list, it
>    would appear to the host as if every plugin library contained every
>    plugin, which could possibly break things and definitely confuse
>    diagnostic tools, and
> 2) the code that accesses that list is not threadsafe, and the LV2
>    spec only guarantees that plugin discovery calls are not
>    executed simultaneously by the host for plugins in the same
>    library, so having a shared list for all libraries could
>    potentially corrupt memory.
>
> liblv2-gui.a has a similar problem.

I removed my hacks and I am building the two libraries static.

SPEC: http://oget.fedorapeople.org/review/lv2-c++-tools.spec
SRPM: http://oget.fedorapeople.org/review/lv2-c++-tools-1.0.3-2.fc12.src.rpm

Some notes:
- I removed the -fno-var-tracking-assignments hack too. gcc seems fixed now. It
takes a little while to compile still. But it doesn't hang.
- There are two static (liblv2-gui.a, liblv2-plugin.a) and one shared
(libpag.so) library. I didn't make a static subpackage since the contents of
the .a files are not the same as the content of the .so file. Is this okay?
What is your opinion?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.