On Sunday 08 May 2011, Erik de wrote:
> Hi all,
>
Hi Eric, sorry for the delay.
> I all I have a rather large Makefile.am that used to work for both
> native compiles on linux and cross compiles from linux to windows.
> This suddenly stopped working with automake 1.11.1 from debian.
>
Which compiler(s) are you using exactly? Which version(s)? More
importantly, which version of libtool are you using? Have you changed
that too recently?
> The relevant parts of the Makefile.am are:
>
> AUTOMAKE_OPTIONS = subdir-objects
>
> noinst_PROGRAMS = test_main$(EXEEXT) G72x/g72x_test$(EXEEXT)
>
> noinst_LTLIBRARIES = GSM610/libgsm.la
>
> G72x_g72x_test_SOURCES = G72x/g72x_test.c
> G72x_g72x_test_LDADD = G72x/libg72x.la
>
> check : $(noinst_PROGRAMS)
> G72x/g72x_test$(EXEEXT) all
> ./test_main$(EXEEXT)
>
Two small pieces of advice:
1. When declaring PROGRAMS, you don't need to add the `$(EXEEXT)'
suffix explicitly to them: automake will automatically do that
for you; for more info, see:
<http://www.gnu.org/software/automake/manual/html_node/EXEEXT.html>
2. When declaring stuff used by the testsuite and that should build
by "make check", you can typically use the `check_' prefix, e.g.:
check_PROGRAMS = test_main G72x/g72x_test
check_LTLIBRARIES = GSM610/libgsm.la
If you do that, you won't need to declare the dependency of `check'
from $(noinst_PROGRAMS).
> The problem is that the test programs don't get built. Or rather
> something gets built and put in the G72x/.libs directory, but there
> is nothing in the G72x/ directory for the generated Makefile to run.
>
And then you add in a follow-up mail:
>
> Just as an addendum to this bug report, the G72x/.libs/ directory
> also contains a file named g72x_test_ltshwrapper. This file is a
> bash script, but is not executable.
>
> However, running it as:
>
> bash G72x/.libs/g72x_test_ltshwrapper
>
> results in the error:
>
> G72x/.libs/g72x_test_ltshwrapper: error:
> `/home/erik/test/src/G72x/.libs/.libs/g72x_test.exe' does not exist
>
> suggesting that the script was actually meant for one directory
> above where it ended up.
I'm not able to reproduce your problem with either my native GCC or my
Linux->MinGW cross compiler (kindly offered by official Debian packages).
And reading the above, I suspect it *might* be a libtool bug.
Could you please provide your libtool and compiler versions, the `ltmain.sh'
file installed by libtoolize, the `Makefile.in' generated by automake, the
`config.log' generated by configure, the relevant output of configure and
make, and the list of files generated in `G72x/.libs' (and everything else
you think could be useful)?
Thanks,
Stefano
