Rtems 4.7 Mingw Tools and automake / LIBTOOL

[Chris Johns]

Ralf Corsepius wrote:
> On Fri, 2006-11-10 at 11:50 +0800, Paul Whitfield wrote:
>> Hi All,
>>
>> I have got myself stuck!
>>
>> I am now using the rtems 4.7 tools for windows from the wiki.
>> (The m68k-3 release).
> Do these override/upgrade the system autotools?

Only the autotools parts that are built as part of the standard RTEMS 
build process in crossrpms.

On my machine I have libtool installed with one of the MSYS packages. I 
am not sure which one. It is version 1.4e. The autotools that ship with 
MSYS are not recent.

> 
>> However, somehow it has broken my autoconf / automake scripts that
>> use the macro
> Well, not quite. You either have broken your autotools installation or
> are using the autotools incorrectly.
> 
>> AC_PROG_LIBTOOL
>>
>> I get an error saying that this  that libtools is
>> undefined and I should use the macro AC_PROG_LIBTOOL.
>>
>> The scripts that do not use this macro work as before.
> This would indicate something is installed incorrectly.
> 
>> configure.in:180: the top level
>> Processing src/ip4/configure.in
>> aclocal -I ../../config
>> Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>> Makefile.am:19:
>> Makefile.am:19: The usual way to define `LIBTOOL' is to add 
>> `AC_PROG_LIBTOOL'
>> Makefile.am:19: to `configure.in' and run `aclocal' and `autoconf' again.
> Hmm, this doesn't match with what you write above.
> 
> Here, one of the autotools (probably autom4te) complains about you not
> using "AC_PROG_LIBTOOL" inside of your configure.in.
> 
> * This could be a simple bug in your configure.in, having not being
> diagnosed in older versions. Adding it to configure.in and rerunning
> aclocal should remedy this.
> 
> 
> * If AC_PROG_LIBTOOL already is in configure.in, then this error could
> indicate the autotools not being able to find libtool's
> m4/aclocal-support files. This would indicate an installation bug. What
> do in this case, depends on details about your installation.
> 
> 
> If you have the rtems autotools installed in parallel to the system
> autotools (This is what the linux packages do), then adding a
> <rtems-autotools>/share/aclocal/dirlist file containing the path to the
> system's aclocal-directory should help:
> 
> On linux this would be:
> # cat /opt/rtems-4.7/share/aclocal/dirlist
> /usr/share/aclocal
> 
> But beware: You'll probably see the autotools complain about *.m4 macros
> other packages might have put there (BTW: This is the cause of the
> winsz.m4 warnings Danilu reported yesterday). These all are bugs of
> these packages and should be fixed by the OS's maintainers.
> 
> A less intrusive approach would be not to use the system's libtool, but
> to install another copy to the same prefix as the RTEMS-autotools.
> This is what I recommend.

I think this is good thing to try.

> 
> If you should have replaced the system autotools with the RTEMS
> autotools, you are having a problem. You'll be facing all kind of bugs
> and defects other packages suffer from in their autotool support files.
> 
> NTB: libtool-1.x is not very well suited to cross building, libtool-2.x
> is reported to be better, but ... there had not been a lease, ever.
> I do not recommend to use libtool for cross-compilation, except if you
> really know what you are doing.
>

Yeap I agree.