Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Simon,
>
> * Simon Josefsson wrote on Tue, Oct 10, 2006 at 03:10:38PM CEST:
>>
>> [EMAIL PROTECTED]:/tmp/jas4711/libidn-0.6.8/gl$ make
>> make all-am
>> if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
>> -I.. -g -O2 -MT ../gl/error.lo -MD -MP -MF ".deps/../gl/error.Tpo" -c
>> -o ../gl/error.lo ../gl/error.c; then mv -f ".deps/../gl/error.Tpo"
>> ".deps/../gl/error.Plo"; else rm -f ".deps/../gl/error.Tpo"; exit 1; fi
>> gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT ../gl/error.lo -MD -MP -MF
>> .deps/../gl/error.Tpo -c ../gl/error.c -fPIC -DPIC -o ../gl/.libs/error.o
>> cc1: No such file or directory: opening dependency file .deps/../gl/error.Tpo
>
>> The problem seems to be that libtool doesn't understand relative
>> dependencies in libgnu_la_DEPENDENCIES, and the -MF parameter becomes
>> wrong.
>
> Most certainly not a Libtool bug. Which exact Automake version is used,
> how can I reproduce this failure easily?
I'm using automake 1.9.6. It isn't easy to reproduce this right now,
since it involves setting up a project with two different gnulib
directories. I can install what I'm working on right now on a CVS
branch in libidn, if you want to take a look.
>> @@ -1137,7 +1138,8 @@ func_emit_lib_Makefile_am ()
>> echo "${libname}_${libext}_SOURCES ="
>> # Here we use $(LIBOBJS), not @[EMAIL PROTECTED] The value is the same.
>> However,
>> # automake during its analyses looks for $(LIBOBJS), not for @[EMAIL
>> PROTECTED]
>> - echo "${libname}_${libext}_LIBADD = \$(${perhapsLT}LIBOBJS)"
>> + echo "${libname}_${libext}_LIBADD =
>> \$(${macro_prefix}_${perhapsLT}LIBOBJS)"
>> + echo "${libname}_${libext}_DEPENDENCIES =
>> \$(${macro_prefix}_${perhapsLT}LIBOBJS)"
>
> You can just drop this last line. Automake can compute these
> dependencies.
Note that we aren't talking about LTLIBOBJS or LIBOBJS, for which
automake indeed seems to do some magic -- this is about foo_LTLIBOBJS,
a replacement that allows multiple OBJDIR's in a project.
If I removed that line, the dependencies (error.lo) weren't built at
all, at least that's the reason I added it.
I may of course still be wrong, of course... but I thought I should
offer an explanation first.
Maybe there is some better way to cause the dependencies to be built,
except libgnu_la_DEPENDENCIES?
/Simon
