bug#9986: libtool-2.4 and MinGW+MSYS

[Earnie]

Charles Wilson wrote:
> 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?
>

MPC configure doesn't support --disable-rpath

> (*) 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)?
>

Attached.

> 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.
>

Attached.

Earnie

tget_version-libtool-debug.txt.gz
Description: application/itunes-itlp

libtool.gz
Description: application/itunes-itlp