-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I tried `make installcheck' with CVS M4, but it failed because dlpreopen'd
libraries were missing:
$ build/m4-1.9a/_inst/bin/m4 --help
$ echo $?
53
$ build/m4-1.9a/_inst/bin/m4 --version
$ echo $?
53
$ file build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4: PE executable for MS Windows (console) Intel
80386 32-bit
$ cygcheck build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4.exe
build/m4-1.9a/_inst/bin\cygm4-0.dll
c:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\cygwin\bin\cygintl-3.dll
c:\cygwin\bin\cygiconv-2.dll
Error: could not find m4-0.dll
Error: could not find traditional-0.dll
Error: could not find gnu-0.dll
Error: could not find gnu-0.dll
Error: could not find gnu-0.dll
Error: could not find m4-0.dll
Error: could not find traditional-0.dll
Aha - a clue - somehow, the installed m4 was compiled in such a way that
it requires the existence of several convenience .dlls.
$ gdb build/m4-1.9a/_inst/bin/m4
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
...
(gdb) b main
Breakpoint 1 at 0x401533: file ../src/main.c, line 230.
(gdb) r
Starting program: /home/eblake/m4-head/build/m4-1.9a/_inst/bin/m4.exe
gdb: unknown target exception 0xc0000135 at 0x7c964ed1
Program received signal ?, Unknown signal.
Program exited with code 030000000465.
You can't do that without a process to debug.
(gdb) q
Sure enough, m4 is dying even before main, with Windows error
STATUS_DLL_NOT_FOUND. But the libraries certainly exist:
$ ls build/m4-1.9a/_inst/libexec/m4/*.dll
build/m4-1.9a/_inst/libexec/m4/gnu-0.dll*
build/m4-1.9a/_inst/libexec/m4/load-0.dll*
build/m4-1.9a/_inst/libexec/m4/m4-0.dll*
build/m4-1.9a/_inst/libexec/m4/mpeval-0.dll*
build/m4-1.9a/_inst/libexec/m4/traditional-0.dll*
$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH cygcheck \
build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4.exe
build/m4-1.9a/_inst/bin\cygm4-0.dll
c:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\cygwin\bin\cygintl-3.dll
c:\cygwin\bin\cygiconv-2.dll
build\m4-1.9a\_inst\libexec\m4\m4-0.dll
build\m4-1.9a\_inst\libexec\m4\traditional-0.dll
build\m4-1.9a\_inst\libexec\m4\gnu-0.dll
That's better - cygcheck likes me when I add libexec/m4 to PATH. And I
can run m4 again, as well as debug the installed copy:
$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH \
build/m4-1.9a/_inst/bin/m4 --help
Usage: build/m4-1.9a/_inst/bin/m4 [OPTION]... [FILE]...
...
Report bugs to <bug-m4@gnu.org>.
$ exit $?
0
$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH gdb --args \
build/m4-1.9a/_inst/bin/m4 --version
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
...
(gdb) b main
Breakpoint 1 at 0x401533: file ../src/main.c, line 230.
(gdb) r
Starting program: /home/eblake/m4-head/build/m4-1.9a/_inst/bin/m4.exe
- --version
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /home/eblake/m4-head/build/m4-1.9a/_inst/bin/cygm4-0.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygintl-3.dll
Loaded symbols for /usr/bin/cygiconv-2.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/m4-0.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/traditional-0.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/gnu-0.dll
Breakpoint 1, main (argc=2, argv=0x6727e8, envp=0x670090) at ../src/main.c:230
230 {
(gdb)
Looking back at the compilation, m4.exe was built with libtool -dlpreopen
of m4, traditional, and gnu convenience libraries. Meanwhile, the load
and mpevel convenience libraries which were also installed, but not
- -dlpreopen'd, so m4.exe does not depend on them existing in PATH. So, my
question is why dlpreopening is creating an executable that statically
depends on the existence of the convenience .dll, but is not installing
those .dlls alongside m4.exe? Either -dlpreopen should make m4.exe link
against the static version of those libraries (so it does not depend on
the convenience .dll existing in PATH), or it should make m4.exe not
depend on the .dll at startup time, but instead do a dlopen() at libltdl
initialization time inside of main() using the knowledge that a properly
installed m4 has .dlls needed for preopening inside libexec/m4.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFAXgn84KuGfSFAYARAjuwAKDDbb++e39VmP+BlkO89zAsEiUKtQCfe+Ii
OgQJGbs3HEWD7n1WPkc0jPE=
=Zgb/
-----END PGP SIGNATURE-----
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
