On Fri, Jun 17, 2011 at 11:58 AM, Tommi Virtanen <tommi.virtanen@xxxxxxxxxxxxx> wrote: > On Thu, Jun 16, 2011 at 05:31:44PM -0700, Colin Patrick McCabe wrote: >> Does anyone know if Automake has a way of expressing dependencies between >> libraries? >> >> For instance, currently our code has this set of (logical) dependencies: >> rbd -> librbd -> librados -> libcommon >> >> Where a -> b means "a depends on symbols found in b". >> >> Unfortunately, the problem that I've run into is that automake seems to have >> no way of expressing dependencies between libraries. >> >> You can do: >> > librbd_la_LIBADD += librados.la >> >> This line does seem to take care of the business of making the final librbd.so >> depend on librados.so. >> >> But you'll still get undefined symbols if you try to use librbd.la later in >> the Makefile.am without also remembering to include librados. So remembering >> the dependencies is up to the developer, which could be a problem if we decide >> to create more libraries (say, by splitting libcommon.) Is there a workaround >> for this? > > This (and the next sections from there on) seem to talk exactly about > this: > > http://sources.redhat.com/autobook/autobook/autobook_76.html#SEC76 > I did follow up on this and it appears that autotool does have the concept of dependencies between libraries. It seems like they want you to express everything in terms of "pseudo-libraries" (that's the .la stuff) and let them figure out the dependencies and how to build it. I wrote a little example and it appears that they do discover dependencies. In fact, it even seems like they create both -fPIC and non-FPIC versions of each .o file in the "pseudo-library". You can see this in the .lo files: > cmccabe@metropolis:~/ceph$ cat src/librados_la-Message.lo > # librados_la-Message.lo - a libtool object file > # Generated by ltmain.sh (GNU libtool) 2.2.6b Debian-2.2.6b-2 > # > # Please DO NOT delete this file! > # It is necessary for linking the library. > > # Name of the PIC object. > pic_object='.libs/librados_la-Message.o' > > # Name of the non-PIC object > non_pic_object='librados_la-Message.o' So in conclusion, I think it should be safe to transition all of our convenience libraries to autotool pseudo-libraries, and let autotool handle building both the -fPIC and non-fPIC versions. The key thing is to do: noinst_LTLIBRARIES += libcommon.la *NOT* lib_LTLIBRARIES += libcommon.la The first one leads to the non-FPIC versions getting used in applications, and no .so file getting installed. The second one leads to libcommon.so getting installed in /usr/lib, and ldd reporting a dynamic dependency between programs and the .so. >> Another problem that I've experienced is that Automake seems to view a >> particular library as either 'shared' or 'static' inherently, and can't handle >> mixing the two. For example, if you do: >> >> > librbd_la_LIBADD += libcommon.a > > As explained in Autobook, libtool does *both*, I think that automake > snippet is just trying to cram a static library in a place that only > expects shared a one. I think the problem is that it needs to be "libcommon.la" cheers, Colin -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
