Previous: Error: ‘required file `./ltmain.sh' not found’, Up: Common Issues Related to Libtool’s Use [Contents][Index]
Sometimes, the same source file is used both to build a libtool library and to build another non-libtool target (be it a program or another library).
Let’s consider the following Makefile.am.
bin_PROGRAMS = prog prog_SOURCES = prog.c foo.c … lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c …
(In this trivial case the issue could be avoided by linking
libfoo.la with prog instead of listing foo.c in
prog_SOURCES
. But let’s assume we really want to keep
prog and libfoo.la separate.)
Technically, it means that we should build foo.$(OBJEXT) for prog, and foo.lo for libfoo.la. The problem is that in the course of creating foo.lo, libtool may erase (or replace) foo.$(OBJEXT), and this cannot be avoided.
Therefore, when Automake detects this situation it will complain with a message such as
object 'foo.$(OBJEXT)' created both with libtool and without
A workaround for this issue is to ensure that these two objects get different basenames. As explained in Why are object files sometimes renamed?, this happens automatically when per-target flags are used.
bin_PROGRAMS = prog prog_SOURCES = prog.c foo.c … prog_CFLAGS = $(AM_CFLAGS) lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c …
Adding ‘prog_CFLAGS = $(AM_CFLAGS)’ is almost a no-op, because
when the prog_CFLAGS
is defined, it is used instead of
AM_CFLAGS
. However as a side effect it will cause
prog.c and foo.c to be compiled as
prog-prog.$(OBJEXT) and prog-foo.$(OBJEXT), which solves
the issue.