I have a problem with my dependency tracking in my auto tools build. I
have a program like this for an embedded target:
-------------------------------------------------
pald_SOURCES = \
$(top_srcdir)/../common/src/pal/main.cpp
if ac_netos_build
pald_SOURCES+=trippUtils.cpp
# From Makefile.appbuild.ns9215, additional code needs to be compiled.
pald_SOURCES+= $(ac_netos_dir)/src/bsp/common/appconf_api.c
pald_CXXFLAGS= -W -Wall -Werror --pedantic -O2 -g -fno-strict-aliasing
-Wno-variadic-macros
pald_LDFLAGS= -Wl,-T,${ac_netos_linkcmd} -Wl,--cref,-Map,pald$(MAP_EXT)
endif
pald_LDADD = $(am_ldadd)
am_ldadd = \
-lstartup
---------------------------------------------------
There are more libraries in am_ldadd, but I wanted to shorten it.
Basically if I use "-lstartup" in my am_ldadd, the "pald" program does not
get relinked if I make a change in "libstartup.a", even though
"libstartup.a" does get relinked. If I change my reference of
libstartup.a from "-lstartup" to "$(top_srcdir)/src/startup/libstartup.a",
then "pald" does relink. What is wrong with using the "-l" instead of
specifying the full library name? I think I had switched to using "-l"
exclusivey because on some platforms I use dynamic libraries instead and I
didn't want to have to rewrite long lists in Makefile.am for platforms
that make dynamic libraries.
I am using the -T {$ac_netos_linkcmd}... Do you think the problem could
be in my linker script, "image.ld" provided by my hardware maker? I
looked inside this file, but it looks like it is just setting up sections
like "_NAAppOffsetInFlash" "_NABootloaderSizeInFlash".
arm-elf$autoconf --version
autoconf (GNU Autoconf) 2.61
arm-elf$automake --version
automake (GNU automake) 1.9.6
arm-elf$aclocal --version
aclocal (GNU automake) 1.9.6
