headers
Eric Blake | 2 Sep 2005 15:29
Gravatar

cygwin build problem with m4 HEAD


I don't know if this is a bug in m4 or in libtool, but with the absolute
latest CVS autoconf, automake, and libtool installed into /usr/local, and
latest CVS m4 plus my patch to fix bootstrap
(http://article.gmane.org/gmane.comp.gnu.m4.patches/229), m4 is failing to
build on cygwin due to:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -O2 -pipe -no-undefined
-export-dynamic  -o m4/libm4.la -rpath /usr/local/lib m4/builtin.lo
m4/debug.lo m4/hash.lo m4/input.lo m4/m4.lo m4/macro.lo m4/module.lo
m4/output.lo m4/path.lo m4/symtab.lo m4/syntax.lo m4/utility.lo
gnu/libgnu.la -lltdl -lintl
libtool: link: rm -fr  m4/.libs/libm4.dll.a
libtool: link: gcc -shared  m4/.libs/builtin.o m4/.libs/debug.o
m4/.libs/hash.o m4/.libs/input.o m4/.libs/m4.o m4/.libs/macro.o
m4/.libs/module.o m4/.libs/output.o m4/.libs/path.o m4/.libs/symtab.o
m4/.libs/syntax.o m4/.libs/utility.o  -Wl,--whole-archive
gnu/.libs/libgnu.a -Wl,--no-whole-archive  /usr/lib/libltdl.dll.a
/usr/lib/libintl.dll.a -L/usr/lib /usr/lib/libiconv.dll.a         -o
m4/.libs/cygm4-0.dll -Wl,--image-base=0x10000000
-Wl,--out-implib,m4/.libs/libm4.dll.a
Creating library file: m4/.libs/libm4.dll.a
m4/.libs/module.o:module.c:(.text+0x6cb): undefined reference to
`_lt_dlhandle_find'
m4/.libs/module.o:module.c:(.text+0x8a5): undefined reference to
`_lt_dlhandle_first'
m4/.libs/module.o:module.c:(.text+0x95e): undefined reference to
`_lt_dlhandle_find'
m4/.libs/module.o:module.c:(.text+0xea): undefined reference to
`_lt_dlhandle_first'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 9 Sep 2005 15:10
Gravatar

HEAD: cygwin make test report - 9 tests failed


After finally tracking down the bug in argz_insert, I finally was able to
run 'make check' without failing every single test (this has bugged me for
more than 9 months now, ever since I volunteered to be the cygwin m4 port
maintainer).  Attached is testsuite.log; it looks like there is still
problems with loading modules on cygwin (for example, 12. builtins.at:178
gmp dies with "m4: cannot open module `mpeval': can't open the module").
Also, some tests look like it might be line-ending related, such as 31.
others.at:293 misc; I'll have to investigate further when I have time.

A quick look in the source tree shows that the module .libs/cygm4-0.dll
and the corresponding link lib .libs/libm4.dll.a are correctly created,
but there are no other dlls created.  This probably explains why modules
`mpeval' and `load' can't be loaded, but how to get those .dlls built is
where I get lost.

Looking back at the compile run, I noticed a couple of warnings that may
be relevant:

...
loaders/loadlibrary.c: In function `vm_open':
loaders/loadlibrary.c:138: warning: implicit declaration of function
`cygwin_conv_to_full_win32_path'
loaders/loadlibrary.c:161: warning: suggest parentheses around assignment
used as truth value
loaders/loadlibrary.c:95: warning: unused variable `errormsg'
...
m4/macro.c: In function `trace_pre':
m4/macro.c:579: warning: conversion lacks type at end of format
m4/macro.c:579: warning: wchar_t format, different type arg (arg 3)
(Continue reading)

Permalink | Reply | 501 comments |
headers
Gary V. Vaughan | 12 Sep 2005 00:12
Face
Picon
Gravatar

Re: HEAD: cygwin make test report - 9 tests failed


Hi Eric,

Eric Blake wrote:
> After finally tracking down the bug in argz_insert, I finally was able
> to run 'make check' without failing every single test (this has bugged
> me for more than 9 months now, ever since I volunteered to be the
> cygwin m4 port maintainer).  Attached is testsuite.log; it looks like
> there is still problems with loading modules on cygwin (for example,
> 12. builtins.at:178 gmp dies with "m4: cannot open module `mpeval':
> can't open the module").  Also, some tests look like it might be
> line-ending related, such as 31.  others.at:293 misc; I'll have to
> investigate further when I have time.

[[excellent bug report details snipped]]

First of all, thank you for tracking down this bug, and looking into the
other portability problems with libtool and m4 you have spent a lot of
time on recently.

I just wanted you to know that your work isn't falling into a black
hole... I'm currently burning all my spare cycles trying to get
libtool-2.0 out the door, and unfortunately m4 has been severely
neglected these last several months as a result.  As soon as libtool-2.0
is unleashed, I plan to switch my efforts back to m4 and look into your
reports properly.

I hope this is okay with you?  And I'm sorry for any frustrations you're
having while I've been looking the other way.
(Continue reading)

Permalink | Reply | 501 comments |
headers
haibin zhang | 13 Sep 2005 05:02
Picon
Favicon

The full runtime environment of Mingw for test

I have built a runtime environmonet of Mingw that
including the newest version of autoconf,
automake,libtool , libiconv and gettext that have been
tested, if you don't have full 
runtime environment of Mingw , you can donwload it
from :
http://sourceforge.net/project/showfiles.php?group_id=148008
(http://sourceforge.net/projects/mingw-install)

regards

zhang haibin

		
___________________________________________________________ 
雅虎邮箱超强增值服务－2G超大空间、pop3收信、无限量邮件提醒 
http://cn.mail.yahoo.com
Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 18 Sep 2005 23:23
Picon
Picon

Re: cygwin build problem with m4 HEAD

Hi Eric,

[ Ccing bug-m4 again ]

* Eric Blake wrote on Fri, Sep 09, 2005 at 02:06:12PM CEST:
> According to Ralf Wildenhues on 9/9/2005 1:31 AM:
> >>>I notice that it is attempting to link against /usr/lib/libltdl.dll.a,
> >>>which comes from libtool 1.5.18, rather than /usr/local/lib/libltdl.dll.a,
> >>>which is my installed libtool 2.1a, and I am pretty sure that
> >>>lt_dlhandle_fi{nd,rst} were added in 2.x, explaining the link failure.
> >>>What I can't track down is why the link command is looking in the wrong
> >>>directory, and thus getting the wrong symbols for libltdl.
> >>
> >>I managed to work around the earlier bug report by configuring m4
> >>using --with- included-ltdl, but it still feels hackish.  I wish I
> >>knew why m4 was trying to link against the wrong libltdl.  In the
> >>meantime, once I was using my workaround, it exposed another bug.

> > Can you post the value of $(LIBLTDL)?
> 
> On a fresh m4 ./configure, without --with-included-ltdl,  <at> LIBLTDL <at>  is
> replaced with -lltdl,  <at> LTDLINCL <at>  with -I${top_srcdir}/ltdl,  <at> INCLTDL <at>  with
> - -I${top_srcdir}/ltdl, and HAVE_LTDL is set to 1.
> 
> On a fresh m4 ./configure --with-included-ltdl,  <at> LIBLTDL <at>  is replaced with
> ${top_builddir}/ltdl/libltdlc.la, LTDLINCL and INCLTDL are unchanged, and
> HAVE_LTDL is no longer defined.

> I have not defined LD_RUN_PATH, /usr/local/bin but not /usr/local/lib was
> in my PATH.  Was there something I was missing when configuring m4 on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 18 Sep 2005 23:41
Picon
Picon

a few glitches in CVS HEAD m4

Hi there,

This is just a few random observations perusing CVS HEAD m4,
for the benefit of Gary when he returns to work on it.  :)

- I get a build failure of src/getopt.c on GNU/Linux glibc-2.3.2:
| In file included from ../m4/src/getopt.c:80:
| ../m4/src/getopt_int.h:26: error: conflicting types for `_getopt_internal'
| /usr/include/getopt.h:173: error: previous declaration of `_getopt_internal'

Dunno if this is an m4 or a gnulib bug, but getopt.c should not be built
on this system, I believe.  Same issue, more errors, with getopt1.c.
Oh, by the way: config.log:
| configure:16967: checking for getopt.h
| configure:17015: result: yes
| configure:17034: checking for getopt_long_only
| configure:17124: result: yes
| configure:17139: checking whether optreset is declared
| configure:17195: result: no
| configure:17204: checking whether getopt_clip is declared
| configure:17260: result: no
...
| GETOPT_H=''

- A couple of proposed tiny patches:

        * bootstrap (RM): quote default.

Index: bootstrap
===================================================================
(Continue reading)

Permalink | Reply | 0 comments |

Gmane