-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ralf,
According to Ralf Wildenhues on 9/8/2006 8:53 AM: > Hello Eric, > > * Eric Blake wrote on Fri, Sep 08, 2006 at 04:03:20PM CEST: >> I tried `make installcheck' with CVS M4, but it failed because dlpreopen'd >> libraries were missing: > *snip* > >> Looking back at the compilation, m4.exe was built with libtool -dlpreopen >> of m4, traditional, and gnu convenience libraries. > > Please, let us have a look, too: at your configure line, at all > libtool --mode=link > lines and their output. Attached a build log of 'make distcheck'. From that log, here is where m4.exe was created: /bin/sh ./libtool --tag=CC --mode=link gcc -g2 -Wall -Werror - -no-undefined -export-dynamic -dlpreopen force -dlpreopen modules/m4.la - -dlpreopen modules/traditional.la -dlpreopen modules/gnu.la -o src/m4.exe src/src_m4-version-etc-fsf.o src/src_m4-version-etc.o src/src_m4-main.o src/src_m4-freeze.o src/src_m4-getopt.o src/src_m4-getopt1.o m4/libm4.la libtool: link: rm -f src/.libs/m4.exe.nm src/.libs/m4.exe.nmS src/.libs/m4.exe.nmT libtool: link: creating src/.libs/m4.exeS.c libtool: link: extracting global C symbols from `modules/.libs/m4.a' libtool: link: extracting global C symbols from `modules/.libs/traditional.a' libtool: link: extracting global C symbols from `modules/.libs/gnu.a' libtool: link: (cd src/.libs && gcc -g2 -Wall -Werror -pipe -c - -fno-builtin "m4.exeS.c") libtool: link: rm -f "src/.libs/m4.exeS.c" "src/.libs/m4.exe.nm" "src/.libs/m4.exe.nmS" "src/.libs/m4.exe.nmT" libtool: link: gcc -g2 -Wall -Werror src/.libs/m4.exeS.o -o src/.libs/m4.exe src/src_m4-version-etc-fsf.o src/src_m4-version-etc.o src/src_m4-main.o src/src_m4-freeze.o src/src_m4-getopt.o src/src_m4-getopt1.o -Wl,--export-dynamic modules/.libs/m4.dll.a - -L/usr/lib modules/.libs/traditional.dll.a modules/.libs/gnu.dll.a /home/eblake/m4-head/build/m4-1.9a/_build/m4/.libs/libm4.dll.a m4/.libs/libm4.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a - -L/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4 - -L/home/eblake/m4-head/build/m4-1.9a/_inst/lib Info: resolving _m4_LTX_m4_builtin_table by linking to __imp__m4_LTX_m4_builtin_table (auto-import) Info: resolving _traditional_LTX_m4_macro_table by linking to __imp__traditional_LTX_m4_macro_table (auto-import) Info: resolving _gnu_LTX_m4_builtin_table by linking to __imp__gnu_LTX_m4_builtin_table (auto-import) Info: resolving _gnu_LTX_m4_macro_table by linking to __imp__gnu_LTX_m4_macro_table (auto-import) Info: resolving _program_name by linking to __imp__program_name (auto-import) libtool: link: creating src/m4.exe > > The issue of dependent DLLs having to exist in $PATH is exactly this bug: > http://lists.gnu.org/archive/html/libtool-patches/2006-09/msg00010.html Indeed. > >> 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), > > That is what -dlpreopen is documented to do. -dlopen should use the > static versions only when shared libs are not available, e.g., due to > --disable-shared or some other reason. Then perhaps the right fix is making -dlpreopen on Windows be a key that the convenience library .dll must be installed alongside the final image in PATH. > > Cheers, and thanks for the report, > Ralf > - -- 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 iD8DBQFFAdMJ84KuGfSFAYARAp1vAJ4w0MaJYMfdvv1UQbcQBqaUtDQ5IgCghsUb hkEQRhudDzTToFDUfpfxLds= =LS9u -----END PGP SIGNATURE-----
m4.log.bz2
Description: Binary data
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
