[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
8.3.9.2 Objects ‘created with both libtool and without’
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-targets 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.