linking convenience libraries to add-on .so and .a libraries.

[Ryan Arnold <ryan dot arnold at gmail dot com>]

Roland, et al.

This email follows the discussion about configuring and building
convenience libraries (that are maintained out of tree) into a GLIBC
add-on.

I've run into some additional issues which could do with some public
documentation.

Let's take for granted that the convenience library 'bar' is only
built as a static library and it is to provide some functionality to
add-on 'foo', in both shared and static versions of libfoo.

Since bar.a is static and we want to pull this archive into libfoo.so
we need to make sure we link with --whole-archive.

Usually this is how we cause a convenience library dependencies to be
created in a GLIBC add-on Makefile:

   $(common-objpfx)foo/bar/libbar.a:
           $(MAKE) -C $(common-objpfx)foo/bar

And this is how we tell GLIBC's implict rules to link bar.a into libfoo.so:

   $(objpfx)libfoo.so: $(common-objpfx)foo/bar/libbar.a

Unfortunately the implict rules which build libfoo.so from the
dependency list doesn't link in bar.a correctly using these rules.

It adds bar.a onto the end of the library list when linking the
dependencies and it ends up being linked following --no-whole-archive
which ends up excluding the contents of archive libbar.a

Instead do the following:

   $(common-objpfx)foo/bar/libbar_pic.a:
           $(MAKE) -C $(common-objpfx)foo/bar
           mv $(common-objpfx)foo/bar/libbar.a
$(common-objpfx)foo/bar/libbar_pic.a

   $(objpfx)libfoo.so: $(common-objpfx)foo/bar/libbar_pic.a

Appending "_pic.a" onto the 'bar' dependency and then making sure that
the convenience library is renamed to libbar_pic.a after it is built
get's libbar_pic.a added into the --whole-archive section of the link
statement.

This is because the implict rule which links libfoo.so based on the
dependency list always adds the "_pic.a" dependencies to the
--whole-archive section of the link statement.

This solves linking libbar_pic.a into libfoo.so (shared object case).

The static case is a bit stickier.  One would think to do:

   $(objpfx)libfoo.a: $(common-objpfx)foo/bar/libbar_pic.a

But this causes the implicit rules that build the add-on lib%.a
(build-extra-lib) to simply tag $(common-objpfx)foo/bar/libbar_pic.a
onto the 'ar' invocation.  This is wrong since 'ar' can't link a '.a'
archive with a bunch of .o files.

What you have to do is generate a series of rules that unpacks the
object files in $(common-objpfx)foo/bar/libbar_pic.a into
$(common-objpfx)foo/ and have those object files in the libfoo.a
dependency list so that the implicit rule picks up the libbar.a .o
files.

The following method is CRUDE but effective.

   libbar-objs = $(common-objpfx)foo/bar1.o $(common-objpfx)foo/bar2.o

   $(libbar-objs): $(common-objpfx)foo/bar/libbar_pic.a
           @(cd $(objpfx) && ar -x $(common-objpfx)foo/bar/libbar_pic.a)

   $(objpfx)libfoo.a: $(libbar-objs)

There must be a way to get the list of .o files from libbar_pic.a
dynamically but I haven't figured that out yet since it depends on
libbar_pic.a being built before the libfoo.a rule is processed.

Ryan S. Arnold