bug#9986: libtool-2.4 and MinGW+MSYS

[Charles Wilson]

On 11/8/2011 8:35 AM, Earnie wrote:
> Charles Wilson wrote:
>> $build is "mingw" do you mean MSYS-shell-in-its-normal-"I-am-mingw"
>> mode?
>>
> 
> Yes.

OK.

>> Also, what are the versions (serial #s) of all of the libtool-related
>> .m4 files in your tree, and what does "<builddir>/libtool --version"
>> report?
> 
> $ ./libtool --version
> libtool (GNU libtool) 2.4

Good.  the MinGW version of libtool has only a few patches relative to
stock libtool-2.4, and none affect this area.

> You can see the bug from svn trunk for MPC.  The tests has a
> tget_version which compares the version of the library DLL to the
> expected test which is how I found the issue.  I've attached the
> --lt-debug output.  See the "lt_update_library_path"  line.
> 
> $ tget_version.exe
> GMP: include 5.0.1, lib 5.0.1
> MPFR: include 2.4.2, lib 2.4.2
> MPC: include 1.0.0dev, lib 0.9
> Error: header and library do not match
> mpc_get_version: "0.9"
> MPC_VERSION_STRING: "1.0.0dev"

Yep, that's a problem alright.

tget_version.exe:./.libs/lt-tget_version.c:705: (lt_update_lib_path)
modifying 'PATH' by prepending
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;'

What's interesting is that the value there, in the C code, is
LIB_PATH_VALUE, and is set thus:

            if test "$shlibpath_overrides_runpath" = yes && test -n
"$shlibpath_var" && test -n "$temp_rpath"; then
              func_to_host_path "$temp_rpath"
              cat <<EOF
const char * LIB_PATH_VALUE   = "$func_to_host_path_result";
EOF
            else
              cat <<"EOF"
const char * LIB_PATH_VALUE   = "";
EOF


Now, since your value is not "", it must have followed the 'true'
branch, so it called func_to_host_path on "$temp_rpath" -- *just like*

            if test -n "$dllsearchpath"; then
              func_to_host_path "$dllsearchpath:"
              cat <<EOF
const char * EXE_PATH_VARNAME = "PATH";
const char * EXE_PATH_VALUE   = "$func_to_host_path_result";


...which worked correctly.  So, there are two possibilities: #1)
something "went wrong" in func_to_host_path(), or the input
"$temp_rpath" was set incorrectly -- perhaps premature conversion of
part of its contents as it was being accumulated (*) prohibited a later
"full" conversion of the entire path?

(*) I notice that the "first accumulated" part /was/ converted to win32
(e:\p\2\mingw\lib) AND had the correct separator appended "between" it
and the previous (empty) contents -- but the "later accumulated" part
(\usr\src\spud\mpc-svn\bld\src\.libs) was not, and was prepended using
':' rather than ';' to separate it from the previous contents...

Could you run the './libtool --mode=link' command for tget_version
manually, with --debug, and post the output (you'll probably want to
attach it compressed)?

Also, just for sanity, I assume your ./libtool script sets

to_host_file_cmd=func_convert_file_msys_to_w32
to_tool_file_cmd=func_convert_file_msys_to_w32

Heck, attach your local ./libtool script to, for good measure.

--
Chuck