GNU bug report logs - #9986
libtool-2.4 and MinGW+MSYS

Previous Next

To reply to this bug, email your comments to 9986 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: bug-libtool <at> gnu.org
Subject: libtool-2.4 and MinGW+MSYS
Date: Mon, 07 Nov 2011 16:20:44 -0500

I've found an issue with the .libs/lt-PROGRAM wrapper in that PATH is
incorrectly prepended to.  Notice below from --lt-debug output that
"\usr\src\spud\mpc-svn\bld\src\.libs:" is prepended to the windows
PATH.  The \usr\src\spud\mpc-svn\bld\src\.libs should have been
translated to e:\p\2\src\spud\mpc-svn\bld\src\.libs and a semi-colon
instead of a colon used as the path separator.

Earnie

targ.exe:./.libs/lt-targ.c:684: (lt_update_exe_path) modifying 'PATH' by
prepending
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;'
targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
targ.exe:./.libs/lt-targ.c:705: (lt_update_lib_path) modifying 'PATH' by
prepending '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;'
targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
targ.exe:./.libs/lt-targ.c:305: (main) lt_argv_zero:
e:/p/2/src/spud/mpc-svn/bld

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Charles Wilson <libtool <at> cwilson.fastmail.fm>
To: Earnie <earnie <at> users.sourceforge.net>
Cc: 9986 <at> debbugs.gnu.org, Libtool Bugs List <bug-libtool <at> gnu.org>
Subject: Re: bug#9986: libtool-2.4 and MinGW+MSYS
Date: Mon, 07 Nov 2011 23:58:53 -0500

On 11/7/2011 4:20 PM, Earnie wrote:
> I've found an issue with the .libs/lt-PROGRAM wrapper in that PATH is
> incorrectly prepended to.  Notice below from --lt-debug output that
> "\usr\src\spud\mpc-svn\bld\src\.libs:" is prepended to the windows
> PATH.  The \usr\src\spud\mpc-svn\bld\src\.libs should have been
> translated to e:\p\2\src\spud\mpc-svn\bld\src\.libs and a semi-colon
> instead of a colon used as the path separator.
>
> Earnie
>
> targ.exe:./.libs/lt-targ.c:684: (lt_update_exe_path) modifying 'PATH' by
> prepending
> '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;'
> targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
> '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
> targ.exe:./.libs/lt-targ.c:705: (lt_update_lib_path) modifying 'PATH' by
> prepending '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;'
> targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
> '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
> targ.exe:./.libs/lt-targ.c:305: (main) lt_argv_zero:
> e:/p/2/src/spud/mpc-svn/bld

As I told you on the mingw list, I'm going to need more information 
about your build environment.  What is $build, and what is $host?  If 
$build is "mingw" do you mean MSYS-shell-in-its-normal-"I-am-mingw" mode?

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?

--
Chuck

Message #11 received at 9986 <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: Charles Wilson <libtool <at> cwilson.fastmail.fm>
Cc: 9986 <at> debbugs.gnu.org, Libtool Bugs List <bug-libtool <at> gnu.org>
Subject: Re: bug#9986: libtool-2.4 and MinGW+MSYS
Date: Tue, 08 Nov 2011 08:35:50 -0500

[Message part 1 (text/plain, inline)]

Charles Wilson wrote:
> On 11/7/2011 4:20 PM, Earnie wrote:
>> I've found an issue with the .libs/lt-PROGRAM wrapper in that PATH
>> is incorrectly prepended to. Notice below from --lt-debug output
>> that "\usr\src\spud\mpc-svn\bld\src\.libs:" is prepended to the
>> windows PATH. The \usr\src\spud\mpc-svn\bld\src\.libs should have
>> been translated to e:\p\2\src\spud\mpc-svn\bld\src\.libs and a
>> semi-colon instead of a colon used as the path separator.
>>
>> Earnie
>>
>> targ.exe:./.libs/lt-targ.c:684: (lt_update_exe_path) modifying
>> 'PATH' by prepending
>> '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;'
>>
>>
targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
>>
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
>>
>>
targ.exe:./.libs/lt-targ.c:705: (lt_update_lib_path) modifying 'PATH' by
>> prepending '\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;'
>> targ.exe:./.libs/lt-targ.c:634: (lt_setenv) setting 'PATH' to
>>
'\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib;\usr\src\spud\mpc-svn\bld\src\.libs:e:\p\2\mingw\lib:e:\p\2\mingw\bin;.;e:\p\2\mingw\bin;E:\p\2\msys\bin;c:\opt\vim\vim73;c:\opt\python27;c:\opt\python27\DLLs;e:\opt\php5;e:\opt\mysql\bin;e:\opt\git\bin'
>>
>>
targ.exe:./.libs/lt-targ.c:305: (main) lt_argv_zero:
>> e:/p/2/src/spud/mpc-svn/bld
>
> As I told you on the mingw list, I'm going to need more information
> about your build environment. What is $build, and what is $host? If
> $build is "mingw" do you mean MSYS-shell-in-its-normal-"I-am-mingw"
> mode?
>

Yes.

> 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
Written by Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


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"

Earnie

[tget_version-lt-debug.txt (text/plain, attachment)]

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Charles Wilson <cwilso11 <at> users.sourceforge.net>
To: Earnie <earnie <at> users.sourceforge.net>
Cc: 9986 <at> debbugs.gnu.org, Libtool Bugs List <bug-libtool <at> gnu.org>
Subject: Re: bug#9986: libtool-2.4 and MinGW+MSYS
Date: Tue, 08 Nov 2011 13:34:11 -0500

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

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: Charles Wilson <cwilso11 <at> users.sourceforge.net>
Cc: 9986 <at> debbugs.gnu.org, Libtool Bugs List <bug-libtool <at> gnu.org>
Subject: Re: bug#9986: libtool-2.4 and MinGW+MSYS
Date: Tue, 08 Nov 2011 16:38:17 -0500

[Message part 1 (text/plain, inline)]

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 (application/x-itunes-itlp, attachment)]

[libtool.gz (application/x-itunes-itlp, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.