bug-make
[Top][All Lists]
Advanced

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

gnu make seems to be dropping part of an LDADD variable ?


From: Rapp, Perry
Subject: gnu make seems to be dropping part of an LDADD variable ?
Date: Fri, 14 Jun 2002 17:37:16 -0400

Abstract:
My link line appears to pull in $(llines_LDADD),
but with a couple of tokens dropped from it,
which I don't understand. I'm no make expert, and
I'm certainly open to suggestions :)


Details:

My explanations are prefixed with greater than symbol (>).


> What is my make ?

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-cygwin
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <address@hidden>.



> This is the failing link line (notice no -liconv).

gcc  -g -O2 -W -Wall -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wreturn-typ
e -Wstrict-prototypes -pedantic -g -DBROKEN_LINKER   -o dbverify.exe
dbverify.o wprintf.o
 ../gedlib/libgedcom.a ../btree/libbtree.a ../stdlib/libstdlib.a
../arch/libarch.a -lintl
../gedlib/libgedcom.a(translat.o): In function `iconv_trans':

> These are the two lines in the actual Makefile that are generating
that link line, AFAIK.
> (And they occur in the following order.)

llines_LDADD = ../interp/libinterp.a ../gedlib/libgedcom.a \
        ../btree/libbtree.a ../stdlib/libstdlib.a ../arch/libarch.a \
        -lintl -liconv

llines$(EXEEXT): $(llines_OBJECTS) $(llines_DEPENDENCIES)
        @rm -f llines$(EXEEXT)
        $(LINK) $(llines_LDFLAGS) $(llines_OBJECTS) $(llines_LDADD)
$(LIBS)

> Notice that -liconv didn't make it into the link line. Also,
../interp/libinterp.a didn't make it.

> But I believe that that llines_LDADD is the source of the actual link
line, because that is where
> the -lintl occurs, unless the -lintl comes from somewhere else --
where else does it occur ?
> A couple places

INTLLIBS = -lintl

> But INTLLIBS occurs nowhere else

LIBINTL = -lintl
LTLIBINTL = -lintl

# Have to explicitly include .. after we put DEFS line in below for
gettext
# .. for config.h, hdrs for lots of stuff, ../intl for libgnuintl.h
INCLUDES = -I.. -I$(srcdir)/../hdrs -I$(srcdir)/../intl

> But LIBINTL only occurs elsewhere in these two lines:

BUILD_INCLUDED_LIBINTL = no
USE_INCLUDED_LIBINTL = no


> Does LDADD occur somewhere else ?

$ grep LDADD liflines/Makefile
llines_LDADD = ../interp/libinterp.a ../gedlib/libgedcom.a \
        $(LINK) $(llines_LDFLAGS) $(llines_OBJECTS) $(llines_LDADD)
$(LIBS)


> (Nope -- these are the two locations from above.)

> Does libstdlib occur anywhere else (as it makes it to the link line) ?

llines_DEPENDENCIES = ../interp/libinterp.a ../gedlib/libgedcom.a \
        ../btree/libbtree.a ../stdlib/libstdlib.a ../arch/libarch.a

> Ok, but even if it were generating the link line from this dependency
list, that doesn't explain how
> -lintl made it into the link line. As mentioned above, there is
nowhere else that could contribute -lintl.



Anyway, any suggestions welcomed :)

Cordially,

Perry

ps: I checked the LDADD multiline target, and the backslash characters
are the last characters
on each line (and if they weren't, then the -lintl should have been
dropped).

pps: This is an Autoconf/Automake project.

autoconf (GNU Autoconf) 2.53a
automake (GNU automake) 1.6.1

ppps: (machine name X'd out)
$ uname -a
CYGWIN_NT-5.0 XXXXXXXXXXX 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown




reply via email to

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