Re: libtool-2.2.6a compiling on MinGW/MSYS fails (for me)

[Dominik Reichardt]

Hi Ralf,

>> I'm trying to get my MinGW/MSYS environment ready and am failing on
>> compiling libtool. It seems to fail with linking libltdl.
>> Can anyone here help me with this or should I take this problem to the
>> MinGW/MSYS mailing list?

> Thanks for the report.  Here's the right place to go.

>> below are the relevant information for this (I hope)
>> 
>> -----------------------------------------------
>> make from where the error starts:
>> /bin/sh ./libtool --tag=CC   --mode=link gcc  -pipe -O2 -mms-bitfields 
>> -march=i686 -no-undefined -version-info 9:0:2 -dlpreopen 
>> libltdl/loadlibrary.la   -o libltdl/libltdl.la -rpath /mingw/lib 
>> libltdl/loaders/libltdl_libltdl_la-preopen.lo 
>> libltdl/libltdl_libltdl_la-lt__alloc.lo 
>> libltdl/libltdl_libltdl_la-lt_dlloader.lo 
>> libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo 
>> libltdl/libltdl_libltdl_la-slist.lo libltdl/argz.lo libltdl/lt__strl.lo
>> libtool: link: not configured to extract global symbols from dlpreopened 
>> files

> This warning is very suspicious.  It causes the build failure.
> Question is what caused the warning ...

> [...]
>> libtool: link: gcc -shared  
>> libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o 
>> libltdl/.libs/libltdl_libltdl_la-lt__alloc.o 
>> libltdl/.libs/libltdl_libltdl_la-lt_dlloader.o 
>> libltdl/.libs/libltdl_libltdl_la-lt_error.o 
>> libltdl/.libs/libltdl_libltdl_la-ltdl.o 
>> libltdl/.libs/libltdl_libltdl_la-slist.o libltdl/.libs/argz.o 
>> libltdl/.libs/lt__strl.o   
>> libltdl/.libs/libltdl.lax/loadlibrary.a/loadlibrary.o    -mms-bitfields 
>> -march=i686   -o libltdl/.libs/libltdl-7.dll -Wl,--enable-auto-image-base 
>> -Xlinker --out-implib -Xlinker libltdl/.libs/libltdl.dll.a
>> Creating library file: libltdl/.libs/libltdl.dll.a
>> libltdl/.libs/libltdl_libltdl_la-ltdl.o:ltdl.c:(.text+0xfb): undefined 
>> reference to `lt_libltdl_LTX_preloaded_symbols'
> [...]

>> complete ./configure
>> 
>> configure: loading site script /mingw/etc/config.site

> Can you please post the contents of /mingw/etc/config.site
> and the output of
>   ./libtool --config

> You might also want to retry building without a cache or site file in
> sight (rm config.cache; CONFIG_SITE=/dev/null ./configure) and see
> whether that changes the failure.

 Just building without the config.site file was successful. Since my
 MinGW/Msys environment is quite old now I don't know where that file
 config.site appeared from.

 The contents of it are
 lt_cv_cc_dll_switch=${lt_cv_cc_dll_switch=-mdll}
lt_cv_compiler_c_o=${lt_cv_compiler_c_o=yes}
lt_cv_compiler_o_lo=${lt_cv_compiler_o_lo=yes}
lt_cv_deplibs_check_method=${lt_cv_deplibs_check_method='file_magic file format 
pei*-i386(.*architecture: i386)?'}
lt_cv_file_magic_cmd=${lt_cv_file_magic_cmd='$OBJDUMP -f'}
lt_cv_file_magic_test_file=${lt_cv_file_magic_test_file=}
test "${lt_cv_global_symbol_to_c_name_address+set}" = set || 
lt_cv_global_symbol_to_c_name_address='sed -n -e '\''s/^: \([^ ]*\) $/  
{\"\1\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \([^ ]*\) \([^ ]*\)$/  {"\2", 
(lt_ptr) \&\2},/p'\'''
lt_cv_global_symbol_to_cdecl=${lt_cv_global_symbol_to_cdecl='sed -n -e '\''s/^. 
.* \(.*\)$/extern char \1;/p'\'''}
lt_cv_ld_reload_flag=${lt_cv_ld_reload_flag=-r}
lt_cv_need_dllmain=${lt_cv_need_dllmain=no}
lt_cv_prog_cc_can_build_shared=${lt_cv_prog_cc_can_build_shared=yes}
lt_cv_prog_cc_no_builtin=${lt_cv_prog_cc_no_builtin=}
lt_cv_prog_cc_pic=${lt_cv_prog_cc_pic='   -DDLL_EXPORT'}
lt_cv_prog_cc_pic_works=${lt_cv_prog_cc_pic_works=yes}
lt_cv_prog_cc_shlib=${lt_cv_prog_cc_shlib=}
lt_cv_prog_cc_static=${lt_cv_prog_cc_static=-static}
lt_cv_prog_cc_static_works=${lt_cv_prog_cc_static_works=yes}
lt_cv_prog_cc_wl=${lt_cv_prog_cc_wl=-Wl,}
lt_cv_prog_gnu_ld=${lt_cv_prog_gnu_ld=yes}
lt_cv_sys_global_symbol_pipe=${lt_cv_sys_global_symbol_pipe=}
lt_cv_sys_path_separator=${lt_cv_sys_path_separator=:}

Is config.site needed anymore or can I permanently move it away?

The output of ./libtool --config is probably irrelevant now that it
built (and also installed).

So you can chalk this up as an error produced by an unclean build
environment :)

Thanks

Dom