automake
[Top][All Lists]
Advanced

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

Re: Automake mingw cross compile problems


From: Stefano Lattarini
Subject: Re: Automake mingw cross compile problems
Date: Fri, 13 May 2011 22:03:15 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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



reply via email to

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