Slibtool build fixes

[orbea]

When building lttng-tools with slibtool (https://dev.midipix.org/cross/slibtool) it fails in many places.

• Many of the tests in tests/unit/ fail with undefined references because they depend on functions compiled into programs and then are linked directly with the .o object files. Build projects that use $(LIBTOOL) should not link the object files themselves and should use .la libtool archives instead. So I created the liblttng-sessiond-comm.la convenience library that will be linked with instead.
• GNU libtool will silently ignore arguments it does not understand in many cases while slibtool will print an error which happens with --no-as-needed which is a linker argument. To solve this it needs to be passed directly to the linker with -Wl,--no-as-needed.

NOTE:

• Each individual commit will still work with GNU libtool.
• This does not solve all of the slibtool issues, the next one may need resolution in slibtool itself and I am making this PR now to avoid having to rebase the work later. Additionally these commits offer general improvements which remove hacks and reduce overlinking.

For reference the next slibtool build failure I see is:

Making install in baddr-statedump
make[4]: Entering directory '/tmp/lttng-tools/tests/regression/ust/baddr-statedump'
objcopy --only-keep-debug prog prog.debug
objcopy: prog: file format not recognized
make[4]: *** [Makefile:810: prog.debug] Error 1
make[4]: Leaving directory '/tmp/lttng-tools/tests/regression/ust/baddr-statedump'
make[3]: *** [Makefile:569: install-recursive] Error 1
make[3]: Leaving directory '/tmp/lttng-tools/tests/regression/ust'
make[2]: *** [Makefile:831: install-recursive] Error 1
make[2]: Leaving directory '/tmp/lttng-tools/tests/regression'
make[1]: *** [Makefile:557: install-recursive] Error 1
make[1]: Leaving directory '/tmp/lttng-tools/tests'
make: *** [Makefile:656: install-recursive] Error 1

This happens because slibtool places compiled binaries in the .libs directory while prog is a shell wrapper script. Ideally some method of --mode=execute could be used to solve this, but may require further work in slibtool itself to work. I will follow up on this PR in the future.

[orbea]

Also see this downstream issue:

https://bugs.gentoo.org/789636

And also reported independently on the slibtool tracker:

https://dev.midipix.org/cross/slibtool/issue/40

[PSRCode]

Hi,

Overall looking good.

Do you have any reference for this:

Build projects that use $(LIBTOOL) should not link the object files themselves and should use .la libtool archives instead.

Cheers

[mjeanson]

The general idea looks good to me, I just have questions on the use of LDFLAGS.

[orbea]

Do you have any reference for this:

Build projects that use $(LIBTOOL) should not link the object files themselves and should use .la libtool archives instead.

Now that I looked again it appears the automake documentation does allow .$(OBJEXT), .a and .la as valid files for LDADD when linking programs.

maude_LDADD

    Extra objects (*.$(OBJEXT)) and libraries (*.a, *.la) can be added to a program by listing them
    in the _LDADD variable. For instance, this should be used for objects determined by configure
    (see Linking).

    _LDADD and _LIBADD are inappropriate for passing program-specific linker flags (except for
    -l, -L, -dlopen and -dlpreopen). Use the _LDFLAGS variable for this purpose.

    For instance, if your configure.ac uses AC_PATH_XTRA, you could link your program against
    the X libraries like so:

        maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)

    We recommend that you use -l and -L only when referring to third-party libraries, and give the
    explicit file names of any library built by your package. Doing so will ensure that
    maude_DEPENDENCIES (see below) is correctly defined by default.

    Since these dependencies are associated with the link rule used to create the programs they
    should normally list files used by the link command. That is *.$(OBJEXT), *.a, or *.la files for
    programs; *.lo and *.la files for Libtool libraries; and *.$(OBJEXT) files for static libraries. 

https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html

However as demonstrated by lttng-tools that linking with .$(OBJEXT) is significantly more complicated and fragile than using a libtool convenience library. With slibtool this results in many undefined references, maybe because of differences in linking order between GNU libtool and slibtool?

[PSRCode]

Thank you linking that info.

However as demonstrated by lttng-tools that linking with .$(OBJEXT) is significantly more complicated and fragile than using a libtool convenience library.

From a quick look, I do agree with you here.

With slibtool this results in many undefined references, maybe because of differences in linking order between GNU libtool and slibtool?

There is a lot more chance that you have a better hunch regarding this than me.

Cheers

[jgalar]

To prevent any confusion, can you rename liblttng-sessiond-comm.la to liblttng-sessiond-common.la?
sessiond-comm already refers to the session daemon's communication facilities internally (e.g. sessiond-comm.h)

Thanks!

[orbea]

To prevent any confusion, can you rename liblttng-sessiond-comm.la to liblttng-sessiond-common.la?

Done.

I added one more commit to fix a new problem I encountered when rebasing the PR.

liblttng-ust-ctl.so: undefined reference to `lttng_ust_sigbus_state'

The fix is described in lttng-ust.

https://github.com/lttng/lttng-ust/blob/21d04cc41c966d687aab6e0ba60b2cb1466356ca/include/lttng/ust-sigbus.h#L36

[jgalar]

@orbea do you mind if I add your Signed-off-by line?

[orbea]

@jgalar I don't mind, but I updated the commits to include it. :)

[jgalar]

Merged manually, thanks!