bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake 1.11 parses if statement too late


From: Ralf Wildenhues
Subject: Re: automake 1.11 parses if statement too late
Date: Mon, 10 Aug 2009 22:50:58 +0200
User-agent: Mutt/1.5.20 (2009-06-15)

Hello,

* Andrew W. Nosenko wrote on Fri, Aug 07, 2009 at 05:05:35PM CEST:
> On Fri, Aug 7, 2009 at 15:23, Bernhard Rosenkraenzer<address@hidden> wrote:
> > this part of a Makefile.am causes errors with automake 1.11:
> >
> > if IPHONE
> > # What ****ing ***** came up with the idea of a platform without shared
> > libraries???

To answer the question: shared libraries are a much younger concept than
static libraries.  In that way the question is the wrong way around.
Why systems without any shared library support are still around, hmm ...

> > lib_LIBRARIES = libtest.a
> > libtest_a_SOURCES = test.cpp
> > libtest_a_LDFLAGS = -lsomelib
> > else
> > lib_LTLIBRARIES = libtest.la
> > libtest_la_SOURCES = test.cpp
> > libtest_la_LDFLAGS = -lsomelib
> > endif

As already stated, libtool was explicitly designed to help you cope
mostly transparently with systems that support only shared, only static,
or both kinds of libraries.  So the above distinction seems to be a
subversion of the libtool scheme, and unnecessary in general.

That said, ...

> > The errors are
> >
> > Makefile.am: object `test.$(OBJEXT)' created both with libtool and without
> > Makefile.am:5: variable `libtest_a_LDFLAGS' is defined but no program or
> > Makefile.am:5: library has `libtest_a' as canonical name (possible typo)
> >
> > Both of the errors should not occur, given the statements in "if ..." and
> > "else" are mutually exclusive and can't be run at the same time.

... sure.  However, automake is a bit picky here, out of necessity.
Unless it sees a(nother) reason for per-target rules, it will use suffix
(inference) rules for test.cpp here, which, as you might have other
objects in this Makefile too, need to be output unconditionally, and
that can generate an awkward situation in this case:

- the .c.$(OBJEXT) rule generates foo.$(OBJEXT) from foo.c
- the .c.lo rule generates foo.lo from foo.c, and also (possibly)
  foo.$(OBJEXT) and one of [._]libs/foo.$(OBJEXT)

If now something else in that Makefile depends upon foo.$(OBJEXT) (in
addition to something depending upon foo.lo), then it might end up being
a timing issue which rule creates foo.$(OBJEXT).  IOW, for example,
parallel make may produce differing results.  Not good.

One way to avoid this is to enforce per-target rules.  See here for more
info:  info Automake "Objects created both with libtool and without".

> Essencially not about your exact question, but why not enforce libtool
> to create static library only (untested, just idea, but should be not
> so far from reality):

> libtest_la_CFLAGS += -static
> libtest_la_LDFLAGS += -static

If the system in question does not support shared libraries, then
libtool will not try to build them, and you won't need to add these
flags in the first place.  So just using:

> lib_LTLIBRARIES = libtest.la
> libtest_la_SOURCES = test.cpp
> libtest_la_LDFLAGS = -lsomelib

and dropping 'if IPHONE' parts, are the way to go.

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]