On Fri, 27 Jan 2012, Daniel van Vugt wrote:

> It looks like the cause is:
>
> target_link_libraries (
>    compiz_core
>
>    ${COMPIZ_LIBRARIES}
>
>    m
>    pthread
>    dl
>
>    -Wl,-whole-archive
>    compiz_string
>    compiz_timer
>    compiz_logmessage
>    compiz_pluginclasshandler
>    compiz_point
>    compiz_rect
>    compiz_window_geometry
>    compiz_window_geometry_saver
>    compiz_window_extents
>    compiz_window_constrainment
>    -Wl,-no-whole-archive
> #    ${CORE_MOD_LIBRARIES}
> )
>
> What we actually want is for compiz_* to be added to compiz_core as
> objects, not as dependent libraries that plugins then mistakenly link
> in. This is easy to do in regular Make, but I'm not sure how to do it in
> CMake. In regular Make you just treat *.a as *.o, but CMake annoyingly
> hides object linkage from us. Maybe it will let us
> add_library(compiz_core SHARED *.a)
>

Well, the plugins are currently linking to libcompiz_core directly (see 
cmake/CompizPlugin.cmake) . This would cause all of the symbols to be 
defined as linked in there.

However, even in this case, if you were linking to libcompiz_core from a 
plugin, then you would expect that the library itself is refcounted like 
you said earlier. So the static data wouldn't be shared. Indeed, this is 
what happens when you disable -Bsymbolic-functions in the cflags. (at 
least for now, I've worked around this by doing this in the packaging, but 
we can't do it for too long because of ubuntu policy: 
https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025367.html). 
Right now it seems though, all static data in libcompiz_core is in fact 
loaded again for every plugin that is loaded (checking the addresses of 
common singletons etc shows this).

Perhaps as you said, the static libraries are being linked statically in 
the plugins instead of being self-contained into libcompiz_core. So they 
are duplicated.

The solution could be to make all the static libraries shared ones and 
just install them, but this feels messy and will increase load times.

(of course, the libraries themselves are needed for making tests)

objdump -S on the plugins could also reveal what is going on too.

(forgive my lack of knowledge on this topic)

> ** Description changed:
>
> - Plugins get a copy of the core classes CompPoint, CompRect, CompTimer
> - etc code duplicated inside them. Obviously this should not happen. The
> - only copy of these classes should be in compiz_core.
> + Plugins get a copy of the core classes CompPoint, CompRect, CompTimer,
> + compiz::window::* duplicated inside them. Obviously this should not
> + happen. The only copy of these classes should be in compiz_core.
>
>  TESTCASE:
>  nm -C lib/compiz/libresize.so | grep ' T '
>
> - You will see a lot of symbols that should be in libcompiz_core.so only
> - (type 'U').
> + You will see a lot of type-T symbols that should only be in
> + libcompiz_core.so. In plugins, those symbols should be type 'U' for
> + undefined.
>
> -- 
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/922199
>
> Title:
>  Duplicate core libraries linked into individual plugins
>
> Status in Compiz Core:
>  Confirmed
>
> Bug description:
>  Plugins get a copy of the core classes CompPoint, CompRect, CompTimer,
>  compiz::window::* duplicated inside them. Obviously this should not
>  happen. The only copy of these classes should be in compiz_core.
>
>  TESTCASE:
>  nm -C lib/compiz/libresize.so | grep ' T '
>
>  You will see a lot of type-T symbols that should only be in
>  libcompiz_core.so. In plugins, those symbols should be type 'U' for
>  undefined.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/922199/+subscriptions
>