bug-automake
[Top][All Lists]
Advanced

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

Rule naming


From: Юрий Пухальский
Subject: Rule naming
Date: Mon, 12 Jul 2010 13:36:59 +0400

Good day to all!

I don't know whether this may be considered a bug or not, but the
following problem exists with native makes on AIX and HP-UX platforms.
Automake is 1.11 on linux.
I make two libraries like this:
noinst_LTLIBRARIES = a.la b.la

And then i use one of them. If i specify @builddir@ explicitly:
a_la_LIBADD = @builddir@/b.la

Then i have <path>/b.la (e.g. ./b.la) in _DEPENDENCIES, and b.la as a target.

While GNU make can cope with this and correctly understands that the
goal is the same, on AIX native make cannot find the rule:

Target './liblog.la' is not supported. Standard targets supported are:
<blabla, that's my output, it has tried to build the dependency and failed>
        /bin/sh ../../libtool --tag=CC    --mode=link cc  -g -AC99
-DHPUX +DD64    -L/oracle/OraHome1/lib -o libcommon_db.la  orautils.lo
des.lo b64.lo pmsgmoney_ut.lo  reinit_task.lo atm_utils.lo get_fee.lo
multicurr.lo  glbl_shrmem_utils.lo trnstore.lo bpc_audit.lo
crypto_func.lo  aes.lo md5.lo havege.lo timing.lo padlock.lo
./liblog.la -lclntsh -lrt -lnsl -lpthread -lm
libtool: link: cannot find the library `./liblog.la' or unhandled
argument `./liblog.la'
*** Error exit code 1

Stop.
hpit:>grep liblog.la Makefile
libcommon_db_la_DEPENDENCIES = ./liblog.la
liblog_la_LIBADD =
am_liblog_la_OBJECTS = debug.lo asc_ebc.lo reopen_outf.lo \
liblog_la_OBJECTS = $(am_liblog_la_OBJECTS)
        $(liblog_la_SOURCES)
        $(liblog_la_SOURCES)
noinst_LTLIBRARIES = libcommon.la libcommon_db.la liblog.la
liblog_la_SOURCES = debug.c asc_ebc.c reopen_outf.c bpc_msglog.c bpc_memory.c \
libcommon_db_la_LIBADD = ./liblog.la
liblog.la: $(liblog_la_OBJECTS) $(liblog_la_DEPENDENCIES)
        $(LINK)  $(liblog_la_OBJECTS) $(liblog_la_LIBADD) $(LIBS)

To be one the safe side it's easiest to add two targets doing the
same, one with builddir prepended and one without. But there could be
@builddir@/../<dir>/ something... Probably it cannot be solved without
analyzing the paths of dependencies.

-- 
«The good thing about standards is there are so many to choose from.»



reply via email to

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