Re: mingw win64 comatibility

[Ralf Wildenhues]

Hallo Alon,

sorry for the long delay.  Please don't top-post, thank you.

* Alon Bar-Lev wrote on Tue, Oct 21, 2008 at 06:20:24PM CEST:
> On 10/21/08, Ralf Wildenhues <address@hidden> wrote:
> >  * Alon Bar-Lev wrote on Mon, Oct 20, 2008 at 03:19:50PM CEST:
> >  > The func_win32_libid is not working correctly when win64 objects are 
> > found.
> >  > The file format is "file format pe-x86-64".
> >  >
> >  > The attached patches for 1.5.26, 2.2.6a for the resulting libtool script.
> >  > I did not know where to put this in libtool source, can you please
> >  > look into it?
> >
> > It needs to be done in libltdl/config/ltmain.m4sh.

> > Can you be bothered to check out the Libtool git tree or a nightly
> >  snapshot (see homepage for links) and, with above change, build it
> >  and run the testsuite on win64, please? [...]

> Used git head.
> Before I use cross compile, I tried to see if all tests pass on local 
> compiler.
> 
> My system (gentoo) has the following versions:
> sys-devel/m4-1.4.11
> sys-devel/autoconf-2.61-r2
> sys-devel/automake-1.10.1-r1
> sys-devel/libtool-1.5.26
> 
> Attached is the native log and win64 log (after the fix).

There are test failures in both native and w64.  Let's address the
native ones first.  I don't understand where this comes from:

| ./old-m4-iface.at:153: CONFIG_SHELL=$SHELL $SHELL ./configure 
$configure_options 
| stderr:
| ./configure: line 7187: Xgcc: command not found
| ./configure: line 7378: conftest.c: command not found
| ./configure: line 7384: -r: command not found
| stdout:
| checking whether make sets $(MAKE)... yes

Can you please do the following:

verify that this command fails:
  make check-local TESTSUITEFLAGS='-v -d -x -k AC_WITH_LTDL'

and post the output, then find out where exactly the failure happens
during configure:
  cd tests/testsuite.dir/42
  ./configure --prefix=/nowhere

You may have to look at the output, and/or config.log.
Do you have the ECHO, RM, environment variables set?


Then there is a set of failures that looks like this:

| ./standalone.at:67: $MAKE $target 
| stderr:
| make[4]: *** No rule to make target `acinclude.m4', needed by `Makefile.in'.
| make[4]: Failed to remake makefile `Makefile'.
| make[4]: Target `all' not remade because of errors.

I'm still hoping those are all just followup failures of the first one.
But in case they are not: does your system have wrappers for autoconf
and/or automake that themselves call different versions of the
underlying tools, based upon some heuristic?  Does the file system that
either the source tree or the build tree live on, have low-accuracy time
stamps (e.g., VFAT)?

> You should add *.exe to ignore... :)

Sorry, I don't understand this comment.  Maybe you're hinting at the
failures fixed with this patch;
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/6268/focus=6636>
and with this (pending, not yet applied) patch:
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/6268/focus=6638>

Let's retest the cross setup when the normal setup is fixed and the
latter patch has been applied.

Thanks,
Ralf