bug-automake
[Top][All Lists]
Advanced

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

Re: LTLIBOBJS not built when using AC_REPLACE_FUNCS without AC_CONFIG_LI


From: Chris Pickett
Subject: Re: LTLIBOBJS not built when using AC_REPLACE_FUNCS without AC_CONFIG_LIBOBJ_DIR
Date: Mon, 29 Dec 2008 19:07:51 -0500
User-agent: Thunderbird 1.5.0.14 (Macintosh/20071210)

Hi Ralf,

Ralf Wildenhues wrote:
Wait a minute.  Even if I add
  libcheck_la_DEPENDENCIES =
  libcheckinternal_la_DEPENDENCIES =

then automake 1.10.2 still fails with
| src/Makefile.am:1: required file `src/strsignal.c' not found

Do you not see that happen?

Oops, I assumed src/strsignal.c was there because in your original example you wrote:

>
> autoreconf -vif  # will error out unless src/strsignal.c exists
>
> ./configure ac_cv_func_strsignal=no  # to fake nonexistent function
> make             # will build and link strsignal.lo

and because I attached it to my original message. touch src/strsignal.c is suffficient.

Now, let's assume you have src/strsignal.c.  Then automake will succeed.

Only with `libcheck_la_DEPENDENCIES =' alone, not if `libcheckinternal_la_DEPENDENCIES =' is there also.

You say that things work OK under OS X but not with MSYS/MinGW.  Can you
please look what configure decides about strsignal there, and show the
failing 'make' output, best in a clean build tree?

OS X:

$ ./configure ac_cv_func_strsignal=no
...
checking for strsignal... (cached) no
...
$ make
...
mv -f .deps/libcheck.Tpo .deps/libcheck.Plo
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libcheck.la -rpath /usr/local/lib libcheck.lo strsignal.lo
mv -f .deps/libcheckinternal.Tpo .deps/libcheckinternal.Plo
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libcheckinternal.la -rpath /usr/local/lib libcheckinternal.lo strsignal.lo libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libcheckinternal.0.dylib .libs/libcheckinternal.o .libs/strsignal.o -install_name /usr/local/lib/libcheckinternal.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libcheck.0.dylib .libs/libcheck.o .libs/strsignal.o -install_name /usr/local/lib/libcheck.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module
...

MSYS/MinGW:

$ ./configure
...
checking for strsignal... no
...
$ make
...
mv -f .deps/libcheck.Tpo .deps/libcheck.Plo
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libcheck.la -rpath /usr/local/lib libcheck.lo strsignal.lo
libtool: link: `strsignal.lo' is not a valid libtool object
make[1]: *** [libcheck.la] Error 1
...

Was that the info you wanted?

However, if you then take out the libcheckinternal bits it fails (correctly) on OS X again. It looks like libcheckinternal is causing strsignal.lo to get built on OS X but not on sys/gcc.

Aside, why do you even need to touch the *_DEPENDENCIES variables at
all?

The following horror:

EXPORT_SYM      = exported.sym
$(EXPORT_SYM): check.h.in
sed -n -e 's/^..*CK_EXPORT[[:space:]][[:space:]]*\([[:alnum:]_][[:alnum:]_]*\)..*$$/\1/p' @top_srcdir@/src/check.h.in > $@

libcheck_la_DEPENDENCIES= $(EXPORT_SYM)
libcheck_la_LDFLAGS     = -export-symbols $(EXPORT_SYM)
libcheck_la_SOURCES     = $(CFILES) $(HFILES)
libcheck_la_LIBADD      = @GCOV_LIBS@

libcheckinternal_la_SOURCES     = $(libcheck_la_SOURCES)
libcheckinternal_la_LIBADD      = @GCOV_LIBS@

At one point it did have @LTLIBOBJS@ in the _DEPENDENCIES line, but I switched to using the lib/ subdir and a libcompat (with an eye towards Gnulib). Is there a better way to write this, besides commoning up @GCOV_LIBS@ in a single LIBADD = @GCOV_LIBS@ line?

* Chris Pickett wrote on Sun, Dec 28, 2008 at 07:31:22AM CET:
In tracking this down, I found out that neither @LTLIBOBJS@ nor @LTALLOCA@ are mentioned in either the "Linking the Program" manual section or the "Program and Library Variables" section in the paragraphs talking about _DEPENDENCIES, although @LIBOBJS@ and @ALLOCA@ are.

Well, but that node deals with linking a program only, not linking a
library.  LTLIBOBJS and LTALLOCA are dealt with when Libtool libraries
are discussed, see
  info Automake "A Shared Libary"
and
  info Automake LTLIBOBJS

While I agree that it might not be obvious, I don't think the "Linking"
node should be filled with those details.  Also, the LIBOBJS node
already hints at LTLIBOBJS.

Fair enough re: Linking the Program, but please consider 1.patch re: Program and Library Variables. As it stands I believe that "only" $(LIBOBJS) and $(ALLOCA) being copied to _DEPENDENCIES is wrong.

to replace the last `.' with `, unless you have already defined *_DEPENDENCIES explicitly for another purpose, in which case you must add these variables manually.' This is consistent with the logic in the previously mentioned sections about *_DEPENDENCIES.

Thanks, I am pushing this, slightly reworded change, both branches, and
adding you to THANKS.

Thanks, glad I could help.

Chris
diff --git a/doc/automake.texi b/doc/automake.texi
index ce4cbcc..9a13454 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5517,11 +5517,13 @@ program are built, consider using the 
@code{BUILT_SOURCES} variable
 
 If @code{_DEPENDENCIES} is not supplied, it is computed by Automake.
 The automatically-assigned value is the contents of @code{_LDADD} or
address@hidden, with most configure substitutions, @option{-l}, @option{-L},
address@hidden and @option{-dlpreopen} options removed.  The configure
-substitutions that are left in are only @samp{$(LIBOBJS)} and
address@hidden(ALLOCA)}; these are left because it is known that they will not
-cause an invalid value for @code{_DEPENDENCIES} to be generated.
address@hidden, with most configure substitutions, @option{-l},
address@hidden, @option{-dlopen} and @option{-dlpreopen} options removed.
+The only configure substitutions that are left in are @samp{$(LIBOBJS)}
+and @samp{$(ALLOCA)} (for programs) and @samp{$(LTLIBOBJS)} and
address@hidden(LTALLOCA)} (for libraries); these are left because it is known
+that they will not cause an invalid value for @code{_DEPENDENCIES} to be
+generated.
 
 @code{_DEPENDENCIES} is more likely used to perform conditional
 compilation using an @code{AC_SUBST} variable that contains a list of

reply via email to

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