I tried all solutions, and it looks like only #1 works. #2 gives the error "/usr/bin/ld: main: hidden symbol `tracepoint_dlopen' in common_tp.a(common_tp.o) is referenced by DSO" when linking. #3 gives the error "./liblibrary.so: undefined reference to `tracepoint_dlopen'" when linking. (Linking is complicated by the fact that LTTng uses special symbol attributes, and tracepoint_dlopen happens to be weak and hidden.) Unless I'm mistaken (and I very well may be), we will have to ensure that all traced code is either 1) placed in a shared library and never statically linked elsewhere, or 2) never linked into any shared library. Thoughts? Adam On Fri, Jul 25, 2014 at 11:48 AM, Adam Crume <adamcrume@xxxxxxxxx> wrote: > LTTng requires tracepoints to be linked into a program only once. If > tracepoints are linked in multiple times, the program crashes at > startup with: "LTTng-UST: Error (-17) while registering tracepoint > probe. Duplicate registration of tracepoint probes having the same > name is not allowed." > > This is problematic when mixing static and dynamic linking. If the > tracepoints are in a static library, that library can end up in an > executable multiple times by being linked in directly, as well as > being statically linked into a dynamic library. Even if the > tracepoints are not linked directly into the executable, they can be > statically linked into multiple dynamic libraries that the executable > loads. > > For us, this problem shows up with libcommon, and could show up with > others such as libosd. (In general, I think anything added to > noinst_LTLIBRARIES is static, and anything added to lib_LTLIBRARIES is > dynamic.) > > There are a few ways of solving the issue: > 1. Change every library that has tracepoints, like libcommon, from > static to dynamic. This could be a big change, as at the very least > we'd have to rename the library to something like libceph_common to > avoid conflicts, since now it would be an installed file. This has > the advantage of keeping code and its tracepoints in the same library. > 2. Keep tracepoints in a separate static library. For example, > libcommon and libcommon_tp. Unfortunately, every executable (but not > library!) that links in libcommon (directly or indirectly) would have > to manually link in libcommon_tp, and I don't think Automake could > automate that. > 3. Keep tracepoints in a separate dynamic library. In this case, I > think libcommon could depend on libcommon_tp, so executables would not > have to manually link in libcommon_tp. (I'm not an Automake expert, > so let me know if I'm wrong on that.) Again, libcommon_tp would be an > installed file, so we'd want to rename it to something like > libceph_common_tp. > > I attached a minimal test case of the problem. > > Thoughts or suggestions? > > Thanks, > Adam Crume
Attachment:
lttng-duplicate-tracepoints-sol1.tar.gz
Description: GNU Zip compressed data
Attachment:
lttng-duplicate-tracepoints-sol2.tar.gz
Description: GNU Zip compressed data
Attachment:
lttng-duplicate-tracepoints-sol3.tar.gz
Description: GNU Zip compressed data
