GNU logs - #15831, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: "Tony Kelman" <kelman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 08 Nov 2013 04:23:02 +0000
Resent-Message-ID: <handler.15831.B.138388456314598 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 15831 <at> debbugs.gnu.org
Message-ID: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>
From: "Tony Kelman" <kelman@HIDDEN>
Date: Thu, 7 Nov 2013 20:12:38 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi all,

I'm working with a set of projects that save their inter-dependencies in
AC_SUBST variables as absolute paths to the relevant .la files. In Cygwin
using the MSVC cl compiler and building only static libraries, I'm seeing
libtool replace the Unix-style absolute path to .la files with the
Unix-style absolute path to the corresponding .libs/<libname>.lib file.
Unsurprisingly, the cl compiler doesn't understand the Unix-style path.
If I modify the Makefile to add `cygpath -w ...` around the absolute path
to the .la file, then libtool instead replaces the Windows-style absolute
path to the .la file with just ./.libs/<libname>.lib, which isn't right
since I'm in a different directory than that library was built in.

My test case here is the COIN-OR Open Solver Interface project
(https://projects.coin-or.org/Osi/wiki) release 0.106.2, but updated to a
recent set of autotools by svn switch'ing the BuildTools directory to
https://projects.coin-or.org/BuildTools/browser/branches/autotools-update.
The same behavior described below happens with the very old libtool
(1.5.22) distributed with the release, but I updated to test whether the
problem still exists in recent libtool. Started Cygwin (64-bit) from the
"VS Command Prompt" to set the right environment variables, and configured
Osi with --enable-doscompile=msvc to use cl compiler.

The problem comes at make test. With the Unix-style absolute path to the
.la file in the variable OSILIB_LIBS, the problem invocation looks like:

/bin/sh ../libtool --tag=CXX -n -v  --mode=link cl  -MT -O2 -nologo -EHsc
  -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG    -DOSI_BUILD   -o
  unitTest.exe unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
  ../src/OsiCommonTest/libOsiCommonTests.la       ../src/Osi/libOsi.la
  /home/Tony/Osi-0.106.2/build02/CoinUtils/src/libCoinUtils.la
libtool: link: cl -MT -O2 -nologo -EHsc -GR -wd4996
  -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG -DOSI_BUILD -o unitTest.exe
  unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
  ../src/OsiCommonTest/.libs/OsiCommonTests.lib ../src/Osi/.libs/Osi.lib
  /home/Tony/Osi-0.106.2/build02/CoinUtils/src/.libs/libCoinUtils.lib
libtool: link: lt_outputfile="unitTest.exe"
libtool: link:  lt_tool_outputfile="unitTest.exe"
libtool: link:  case  in *.exe|*.EXE) ;; *) lt_outputfile=".exe"
  lt_tool_outputfile=".exe" ;; esac
libtool: link:  func_to_tool_file ""
libtool: link:  if test "mt" != ":" && test -f ".manifest"; then mt
  -manifest ".manifest" -outputresource:"" || exit 1; rm -f ".manifest"; fi

If I take out -n from AM_LIBTOOLFLAGS then I get hundreds of unresolved
externals to everything from libCoinUtils, since cl ignored the "unknown
option" of the Unix-style absolute path to libCoinUtils.la.

Adding `cygpath -w ...` around the absolute path to libCoinUtils.la in the
Osi/test/Makefile variable OSILIB_LIBS results in the following:

/bin/sh ../libtool --tag=CXX -v  --mode=link cl  -MT -O2 -nologo -EHsc
  -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG    -DOSI_BUILD   -o
  unitTest.exe unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
  ../src/OsiCommonTest/libOsiCommonTests.la       ../src/Osi/libOsi.la
  `cygpath -w /home/Tony/Osi-0.106.2/build02/CoinUtils/src/libCoinUtils.la`
libtool: link: cl -MT -O2 -nologo -EHsc -GR -wd4996
  -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG -DOSI_BUILD -o unitTest.exe
  unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
  ../src/OsiCommonTest/.libs/OsiCommonTests.lib ../src/Osi/.libs/Osi.lib
  ./.libs/libCoinUtils.lib
cl : Command line warning D9035 : option 'o' has been deprecated and will
  be removed in a future release
LINK : fatal error LNK1181: cannot open input file 
'./.libs/libCoinUtils.lib'
libtool: link: lt_outputfile="unitTest.exe"
libtool: link:  lt_tool_outputfile="unitTest.exe"
libtool: link:  case unitTest.exe in *.exe|*.EXE) ;; *)
  lt_outputfile="unitTest.exe.exe" lt_tool_outputfile="unitTest.exe.exe" ;; 
esac
libtool: link:  func_to_tool_file "unitTest.exe"
libtool: link:  if test "mt" != ":" && test -f "unitTest.exe.manifest";
  then mt -manifest "unitTest.exe.manifest" -outputresource:"unitTest.exe"
  || exit 1; rm -f "unitTest.exe.manifest"; fi
Makefile:476: recipe for target 'unitTest.exe' failed
make: *** [unitTest.exe] Error 2

Is this a bug in libtool, or am I doing something wrong/unsupported? MSYS
works better here, but it would be ideal to be able to use Cygwin as well.

Relevant info from the end of libtool --help:

host-triplet:    x86_64-unknown-cygwin
shell:        /bin/sh
compiler:        cl
compiler 
flags:        -MT -O2 -nologo -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG
linker:        link (gnu? no)
libtool:    (GNU libtool) 2.4.2
automake:
autoconf:    autoconf (GNU Autoconf) 2.69

Automake was version 1.12, not sure why libtool didn't see that.

Appreciate any advice here, let me know if there's any more information I
can provide that would be useful.

-Tony

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Tony Kelman" <kelman@HIDDEN>
Subject: bug#15831: Acknowledgement (Absolute library paths with Cygwin +
 MSVC cl)
Message-ID: <handler.15831.B.138388456314598.ack <at> debbugs.gnu.org>
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>
X-Gnu-PR-Message: ack 15831
X-Gnu-PR-Package: libtool
Reply-To: 15831 <at> debbugs.gnu.org
Date: Fri, 08 Nov 2013 04:23:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 15831 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
15831: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15831
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-libtool@HIDDEN:

Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: Peter Rosin <peda@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 08 Nov 2013 14:47:02 +0000
Resent-Message-ID: <handler.15831.B15831.138392201813761 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Tony Kelman <kelman@HIDDEN>, 15831 <at> debbugs.gnu.org
Message-ID: <527CF95D.7020707@HIDDEN>
Date: Fri, 08 Nov 2013 15:46:53 +0100
From: Peter Rosin <peda@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>
In-Reply-To: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On 2013-11-08 05:12, Tony Kelman wrote:
> Hi all,
> 
> I'm working with a set of projects that save their inter-dependencies in
> AC_SUBST variables as absolute paths to the relevant .la files. In Cygwin
> using the MSVC cl compiler and building only static libraries, I'm seeing
> libtool replace the Unix-style absolute path to .la files with the
> Unix-style absolute path to the corresponding .libs/<libname>.lib file.
> Unsurprisingly, the cl compiler doesn't understand the Unix-style path.
> If I modify the Makefile to add `cygpath -w ...` around the absolute path
> to the .la file, then libtool instead replaces the Windows-style absolute
> path to the .la file with just ./.libs/<libname>.lib, which isn't right
> since I'm in a different directory than that library was built in.
> 
> My test case here is the COIN-OR Open Solver Interface project
> (https://projects.coin-or.org/Osi/wiki) release 0.106.2, but updated to a
> recent set of autotools by svn switch'ing the BuildTools directory to
> https://projects.coin-or.org/BuildTools/browser/branches/autotools-update.
> The same behavior described below happens with the very old libtool
> (1.5.22) distributed with the release, but I updated to test whether the
> problem still exists in recent libtool. Started Cygwin (64-bit) from the
> "VS Command Prompt" to set the right environment variables, and configured
> Osi with --enable-doscompile=msvc to use cl compiler.
> 
> The problem comes at make test. With the Unix-style absolute path to the
> .la file in the variable OSILIB_LIBS, the problem invocation looks like:
> 
> /bin/sh ../libtool --tag=CXX -n -v  --mode=link cl  -MT -O2 -nologo -EHsc
>  -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG    -DOSI_BUILD   -o
>  unitTest.exe unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
>  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
>  ../src/OsiCommonTest/libOsiCommonTests.la       ../src/Osi/libOsi.la
>  /home/Tony/Osi-0.106.2/build02/CoinUtils/src/libCoinUtils.la
> libtool: link: cl -MT -O2 -nologo -EHsc -GR -wd4996
>  -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG -DOSI_BUILD -o unitTest.exe
>  unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
>  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
>  ../src/OsiCommonTest/.libs/OsiCommonTests.lib ../src/Osi/.libs/Osi.lib
>  /home/Tony/Osi-0.106.2/build02/CoinUtils/src/.libs/libCoinUtils.lib
> libtool: link: lt_outputfile="unitTest.exe"
> libtool: link:  lt_tool_outputfile="unitTest.exe"
> libtool: link:  case  in *.exe|*.EXE) ;; *) lt_outputfile=".exe"
>  lt_tool_outputfile=".exe" ;; esac
> libtool: link:  func_to_tool_file ""
> libtool: link:  if test "mt" != ":" && test -f ".manifest"; then mt
>  -manifest ".manifest" -outputresource:"" || exit 1; rm -f ".manifest"; fi
> 
> If I take out -n from AM_LIBTOOLFLAGS then I get hundreds of unresolved
> externals to everything from libCoinUtils, since cl ignored the "unknown
> option" of the Unix-style absolute path to libCoinUtils.la.
> 
> Adding `cygpath -w ...` around the absolute path to libCoinUtils.la in the
> Osi/test/Makefile variable OSILIB_LIBS results in the following:
> 
> /bin/sh ../libtool --tag=CXX -v  --mode=link cl  -MT -O2 -nologo -EHsc
>  -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG    -DOSI_BUILD   -o
>  unitTest.exe unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
>  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
>  ../src/OsiCommonTest/libOsiCommonTests.la       ../src/Osi/libOsi.la
>  `cygpath -w /home/Tony/Osi-0.106.2/build02/CoinUtils/src/libCoinUtils.la`
> libtool: link: cl -MT -O2 -nologo -EHsc -GR -wd4996
>  -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG -DOSI_BUILD -o unitTest.exe
>  unitTest.obj OsiTestSolver.obj OsiTestSolverInterface.obj
>  OsiTestSolverInterfaceIO.obj OsiTestSolverInterfaceTest.obj
>  ../src/OsiCommonTest/.libs/OsiCommonTests.lib ../src/Osi/.libs/Osi.lib
>  ./.libs/libCoinUtils.lib
> cl : Command line warning D9035 : option 'o' has been deprecated and will
>  be removed in a future release
> LINK : fatal error LNK1181: cannot open input file './.libs/libCoinUtils.lib'
> libtool: link: lt_outputfile="unitTest.exe"
> libtool: link:  lt_tool_outputfile="unitTest.exe"
> libtool: link:  case unitTest.exe in *.exe|*.EXE) ;; *)
>  lt_outputfile="unitTest.exe.exe" lt_tool_outputfile="unitTest.exe.exe" ;; esac
> libtool: link:  func_to_tool_file "unitTest.exe"
> libtool: link:  if test "mt" != ":" && test -f "unitTest.exe.manifest";
>  then mt -manifest "unitTest.exe.manifest" -outputresource:"unitTest.exe"
>  || exit 1; rm -f "unitTest.exe.manifest"; fi
> Makefile:476: recipe for target 'unitTest.exe' failed
> make: *** [unitTest.exe] Error 2
> 
> Is this a bug in libtool, or am I doing something wrong/unsupported? MSYS
> works better here, but it would be ideal to be able to use Cygwin as well.
> 
> Relevant info from the end of libtool --help:
> 
> host-triplet:    x86_64-unknown-cygwin
> shell:        /bin/sh
> compiler:        cl
> compiler flags:        -MT -O2 -nologo -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG
> linker:        link (gnu? no)
> libtool:    (GNU libtool) 2.4.2
> automake:
> autoconf:    autoconf (GNU Autoconf) 2.69
> 
> Automake was version 1.12, not sure why libtool didn't see that.
> 
> Appreciate any advice here, let me know if there's any more information I
> can provide that would be useful.

Using the terminology from [1], there are two options for building with
cl on Cygwin. You either fake it or you lie. I recommend faking it.

For that to have any chance to work with absolute file names, you have to
include lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 as one of
your configure arguments (or do as [1] suggests and
   export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
but I prefer to add it as a configure arg, it is then preserved even if
the project happens to be reconfigured from some other environment w/o
that export).

If you instead lie, you also need
  lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32

It was not clear from your message if you had taken care of that detail?

Cheers,
Peter

[1] http://www.gnu.org/software/libtool/manual/html_node/Cygwin-to-MinGW-Cross.html

Message sent to bug-libtool@HIDDEN:

Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: "Tony Kelman" <kelman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 09 Nov 2013 00:43:01 +0000
Resent-Message-ID: <handler.15831.B15831.138395775418135 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Peter Rosin" <peda@HIDDEN>, <15831 <at> debbugs.gnu.org>
Message-ID: <3707CB95EA4149B581E14902F8B82621@TKsamsung>
From: "Tony Kelman" <kelman@HIDDEN>
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>
 <527CF95D.7020707@HIDDEN>
In-Reply-To: <527CF95D.7020707@HIDDEN>
Date: Fri, 8 Nov 2013 16:42:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Using the terminology from [1], there are two options for building with
> cl on Cygwin. You either fake it or you lie. I recommend faking it.
> 
> For that to have any chance to work with absolute file names, you have to
> include lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 as one of
> your configure arguments (or do as [1] suggests and
>    export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
> but I prefer to add it as a configure arg, it is then preserved even if
> the project happens to be reconfigured from some other environment w/o
> that export).
> 
> If you instead lie, you also need
>   lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
> 
> It was not clear from your message if you had taken care of that detail?

Thanks very much for the info. I tried providing the lt_cv_to_tool_file_cmd
to configure, either with and without --host=x86_64-w64-mingw32, but did
not manage to get libtool to send cl the Windows path to libCoinUtils.lib.
Manually replacing the absolute Cygwin path in the Makefile with either a
relative path or a `cygpath -m ...` mixed path with forward slashes worked.

While it would be great if libtool could do this for me in a simple way,
it seems it's a bit challenging to get working. Compiling with cl is
already heavily special-cased in the COIN-OR build system, so I can modify
one of their autoconf macros that populate the Makefile variables in the
first place to handle this. They're already doing a cygpath -m type path
substitution on any absolute paths to .lib files in the _LIBS variables,
and in initial tests extending that to (.lib|.la) seems to be working.

-Tony

Message sent to bug-libtool@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: Peter Rosin <peda@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 09 Nov 2013 01:14:01 +0000
Resent-Message-ID: <handler.15831.B15831.138395963521203 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15831
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Tony Kelman <kelman@HIDDEN>, 15831 <at> debbugs.gnu.org
Received: via spool by 15831-submit <at> debbugs.gnu.org id=B15831.138395963521203
          (code B ref 15831); Sat, 09 Nov 2013 01:14:01 +0000
Received: (at 15831) by debbugs.gnu.org; 9 Nov 2013 01:13:55 +0000
Received: from localhost ([127.0.0.1]:42970 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vex7a-0005Vu-Tj
	for submit <at> debbugs.gnu.org; Fri, 08 Nov 2013 20:13:55 -0500
Received: from mail.lysator.liu.se ([130.236.254.3]:47157)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <peda@HIDDEN>) id 1Vex7X-0005Vk-KL
 for 15831 <at> debbugs.gnu.org; Fri, 08 Nov 2013 20:13:53 -0500
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
 by mail.lysator.liu.se (Postfix) with ESMTP id E727D4000A;
 Sat,  9 Nov 2013 02:13:49 +0100 (CET)
Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com
 [90.227.119.137])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.lysator.liu.se (Postfix) with ESMTPSA id 91D3740006;
 Sat,  9 Nov 2013 02:13:49 +0100 (CET)
Message-ID: <527D8C4E.1080903@HIDDEN>
Date: Sat, 09 Nov 2013 02:13:50 +0100
From: Peter Rosin <peda@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>	<527CF95D.7020707@HIDDEN>
 <3707CB95EA4149B581E14902F8B82621@TKsamsung>
In-Reply-To: <3707CB95EA4149B581E14902F8B82621@TKsamsung>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

On 2013-11-09 01:42, Tony Kelman wrote:
>> Using the terminology from [1], there are two options for building with
>> cl on Cygwin. You either fake it or you lie. I recommend faking it.
>>
>> For that to have any chance to work with absolute file names, you have to
>> include lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 as one of
>> your configure arguments (or do as [1] suggests and
>>    export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>> but I prefer to add it as a configure arg, it is then preserved even if
>> the project happens to be reconfigured from some other environment w/o
>> that export).
>>
>> If you instead lie, you also need
>>   lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
>>
>> It was not clear from your message if you had taken care of that detail?
> 
> Thanks very much for the info. I tried providing the lt_cv_to_tool_file_cmd
> to configure, either with and without --host=x86_64-w64-mingw32, but did
> not manage to get libtool to send cl the Windows path to libCoinUtils.lib.
> Manually replacing the absolute Cygwin path in the Makefile with either a
> relative path or a `cygpath -m ...` mixed path with forward slashes worked.
> 
> While it would be great if libtool could do this for me in a simple way,
> it seems it's a bit challenging to get working. Compiling with cl is
> already heavily special-cased in the COIN-OR build system, so I can modify
> one of their autoconf macros that populate the Makefile variables in the
> first place to handle this. They're already doing a cygpath -m type path
> substitution on any absolute paths to .lib files in the _LIBS variables,
> and in initial tests extending that to (.lib|.la) seems to be working.

Hmm, looking a bit closer to your command and the output, I now notice
one thing. Why do you specified an absolute path to libCoinUtils.la in
the first place? I beleive that this isn't according to best practices.
You should either use a -L flag or a relative file name. Does it
work to say
"-L/home/Tony/Osi-0.106.2/build02/CoinUtils/src -lCoinUtils" instead?

I also notice that libCoinUtils.la appears to unfold into
libCoinUtils.lib which seems a bit strange, I would have expected a
straight CoinUtils.lib instead (no lib prefix), not that I think it
matters as long as it's consistent. But how was libCoinUtils.la
produced? Is it a libtool convenience library, or an ordinary library?

Screeech. Stop. Wait a minute. You have not wrapped cl with the
'compile' script (from Automake). The above suggestion will not
work if you don't, I just assumed that it already was in the mix.
My bad. The easiest way to add that script to the project is to add
AM_PROG_CC_C_O to configure.ac (after AC_PROG_CC). Since this is
C++, you will then have to manually say CXX="/path/to/compile cl"
when you configure. Sorry for not noticing earlier.

Cheers,
Peter

Message sent to bug-libtool@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: "Tony Kelman" <kelman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 09 Nov 2013 03:13:02 +0000
Resent-Message-ID: <handler.15831.B15831.1383966752359 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15831
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: "Peter Rosin" <peda@HIDDEN>, <15831 <at> debbugs.gnu.org>
Received: via spool by 15831-submit <at> debbugs.gnu.org id=B15831.1383966752359
          (code B ref 15831); Sat, 09 Nov 2013 03:13:02 +0000
Received: (at 15831) by debbugs.gnu.org; 9 Nov 2013 03:12:32 +0000
Received: from localhost ([127.0.0.1]:43210 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VeyyN-00005i-SN
	for submit <at> debbugs.gnu.org; Fri, 08 Nov 2013 22:12:32 -0500
Received: from mail-pb0-f45.google.com ([209.85.160.45]:60192)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <kelman@HIDDEN>) id 1VeyyM-00005U-A4
 for 15831 <at> debbugs.gnu.org; Fri, 08 Nov 2013 22:12:31 -0500
Received: by mail-pb0-f45.google.com with SMTP id ma3so2952133pbc.4
 for <15831 <at> debbugs.gnu.org>; Fri, 08 Nov 2013 19:12:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:from:to:references:in-reply-to
 :subject:date:mime-version:content-type:content-transfer-encoding
 :importance;
 bh=uEw+Kj5SF5B1bKcgHinoGzkQNx8iLJywQNEFkBvGjfY=;
 b=SyhyU6/f9aU2v8n0mhET/fQAhbdCmWuz/5iD1fhVhsA4cWFEO8Lcnm16wzMYhT46aP
 3YCun5qrVknps2vL0aHmInm5pVU4RHOeqV2uGBdXHWrWDR4WHA3H/jxuKkBv/eLZ+JgA
 3PAo4weFerjYg2MG2DjQzTizSoR2cP00J/DJtAItuceKXQhO7DI0NHMHmsrlor0lMomc
 ftVvvxNKlGBbX6rLSLRiaEfhxi7dvzpRynZAFmHFUEk3x4JPHcMFmqWsV5cehC870jSW
 4qdxTSKbt5DmLpoBCXsigf0TndLt1agJN3sYzqqtccyXmTUZLRXxkwBUxsMq3/gRR/Nl
 GBpw==
X-Gm-Message-State: ALoCoQkQcJ16f5UH/bfxSvk5UxoBJCDCY/fkmqneIH+uYYgWCxPefSmzdn3Hz8l1lrVKo9ZYkuSD
X-Received: by 10.68.189.133 with SMTP id gi5mr18336421pbc.57.1383966744222;
 Fri, 08 Nov 2013 19:12:24 -0800 (PST)
Received: from TKsamsung (airbears-136-152-29-2.AirBears.Berkeley.EDU.
 [136.152.29.2])
 by mx.google.com with ESMTPSA id hi5sm15327563pbb.43.2013.11.08.19.12.23
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Fri, 08 Nov 2013 19:12:23 -0800 (PST)
Message-ID: <E59760E7A9E64F74895558DBA43C8C54@TKsamsung>
From: "Tony Kelman" <kelman@HIDDEN>
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>	<527CF95D.7020707@HIDDEN>
 <3707CB95EA4149B581E14902F8B82621@TKsamsung>
 <527D8C4E.1080903@HIDDEN>
In-Reply-To: <527D8C4E.1080903@HIDDEN>
Date: Fri, 8 Nov 2013 19:12:15 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-Spam-Score: -0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

> Hmm, looking a bit closer to your command and the output, I now notice
> one thing. Why do you specified an absolute path to libCoinUtils.la in
> the first place? I beleive that this isn't according to best practices.
> You should either use a -L flag or a relative file name. Does it
> work to say
> "-L/home/Tony/Osi-0.106.2/build02/CoinUtils/src -lCoinUtils" instead?

The makefile variables with these absolute paths are populated by parsing
<proj>-uninstalled.pc files (even on systems without pkg-config). The
justification for why COIN-OR does it that way is described here
https://projects.coin-or.org/BuildTools/wiki/pm-pcfile#The.pcfileofanuninstalledCOIN-ORprojectlibrary
It's used to populate dependencies, evidently the standard way automake
does that would not work for them since they have dependencies that can
change at configure time.

> I also notice that libCoinUtils.la appears to unfold into
> libCoinUtils.lib which seems a bit strange, I would have expected a
> straight CoinUtils.lib instead (no lib prefix), not that I think it
> matters as long as it's consistent. But how was libCoinUtils.la
> produced? Is it a libtool convenience library, or an ordinary library?

It's a libtool convenience library. Produced by usual automake process.
https://projects.coin-or.org/CoinUtils/browser/trunk/CoinUtils/src/Makefile.am#L11

> Screeech. Stop. Wait a minute. You have not wrapped cl with the
> 'compile' script (from Automake). The above suggestion will not
> work if you don't, I just assumed that it already was in the mix.
> My bad. The easiest way to add that script to the project is to add
> AM_PROG_CC_C_O to configure.ac (after AC_PROG_CC). Since this is
> C++, you will then have to manually say CXX="/path/to/compile cl"
> when you configure. Sorry for not noticing earlier.

Aha, that compile script seems much more useful these days than it was
back in automake 1.9.6, which is what COIN-OR has been using for too long.
That works in my tests so far, sorry for wanting libtool to do a job that
a different tool already handles. It looks like using the compile script
should simplify matters and allow the COIN-OR folks to get rid of many of
their custom macros. I'll let them know they should transition to using
it as part of moving to newer autotools.

-Tony

Message sent to bug-libtool@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Resent-From: Peter Rosin <peda@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 09 Nov 2013 10:17:02 +0000
Resent-Message-ID: <handler.15831.B15831.13839922119125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15831
X-GNU-PR-Package: libtool
X-GNU-PR-Keywords: 
To: Tony Kelman <kelman@HIDDEN>, 15831 <at> debbugs.gnu.org
Received: via spool by 15831-submit <at> debbugs.gnu.org id=B15831.13839922119125
          (code B ref 15831); Sat, 09 Nov 2013 10:17:02 +0000
Received: (at 15831) by debbugs.gnu.org; 9 Nov 2013 10:16:51 +0000
Received: from localhost ([127.0.0.1]:43662 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vf5b0-0002N6-LS
	for submit <at> debbugs.gnu.org; Sat, 09 Nov 2013 05:16:51 -0500
Received: from mail.lysator.liu.se ([130.236.254.3]:45120)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <peda@HIDDEN>) id 1Vf5ay-0002Mr-91
 for 15831 <at> debbugs.gnu.org; Sat, 09 Nov 2013 05:16:49 -0500
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
 by mail.lysator.liu.se (Postfix) with ESMTP id D451540060;
 Sat,  9 Nov 2013 11:16:46 +0100 (CET)
Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com
 [90.227.119.137])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.lysator.liu.se (Postfix) with ESMTPSA id 7E39440028;
 Sat,  9 Nov 2013 11:16:46 +0100 (CET)
Message-ID: <527E0B90.9070706@HIDDEN>
Date: Sat, 09 Nov 2013 11:16:48 +0100
From: Peter Rosin <peda@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
References: <013C6C5A7FBA49B9B3494B3E9AC6A1BF@TKsamsung>	<527CF95D.7020707@HIDDEN>	<3707CB95EA4149B581E14902F8B82621@TKsamsung>	<527D8C4E.1080903@HIDDEN>
 <E59760E7A9E64F74895558DBA43C8C54@TKsamsung>
In-Reply-To: <E59760E7A9E64F74895558DBA43C8C54@TKsamsung>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

On 2013-11-09 04:12, Tony Kelman wrote:
>> I also notice that libCoinUtils.la appears to unfold into
>> libCoinUtils.lib which seems a bit strange, I would have expected a
>> straight CoinUtils.lib instead (no lib prefix), not that I think it
>> matters as long as it's consistent. But how was libCoinUtils.la
>> produced? Is it a libtool convenience library, or an ordinary library?
> 
> It's a libtool convenience library. Produced by usual automake process.
> https://projects.coin-or.org/CoinUtils/browser/trunk/CoinUtils/src/Makefile.am#L11

Ok.

>> Screeech. Stop. Wait a minute. You have not wrapped cl with the
>> 'compile' script (from Automake). The above suggestion will not
>> work if you don't, I just assumed that it already was in the mix.
>> My bad. The easiest way to add that script to the project is to add
>> AM_PROG_CC_C_O to configure.ac (after AC_PROG_CC). Since this is
>> C++, you will then have to manually say CXX="/path/to/compile cl"
>> when you configure. Sorry for not noticing earlier.
> 
> Aha, that compile script seems much more useful these days than it was
> back in automake 1.9.6, which is what COIN-OR has been using for too long.
> That works in my tests so far, sorry for wanting libtool to do a job that
> a different tool already handles. It looks like using the compile script
> should simplify matters and allow the COIN-OR folks to get rid of many of
> their custom macros. I'll let them know they should transition to using
> it as part of moving to newer autotools.

Yes, the cl side of 'compile' is new since Automake 1.9.6 (8 years old)...
One thing that's still missing is that there is no trigger for it when
using C++.

I'm mostly responding here to hint that there is nothing stopping you
from shipping a recent 'compile' script even if you bootstrap with
Automake 1.9.6, in case there are other reasons that prevent an
Automake upgrade. Or you can just have a private copy of a recent
'compile' script in case it's not feasible to ship a recent 'compile'
script within the project for some political reason.

You might also be interested in the 'ar-lib' script and the AM_PROG_AR
macro that does to lib.exe what 'compile' does to cl, sort of. But
I don't know if you build any old static libraries w/o help from libtool.
Probably not, but just in case...

Cheers,
Peter

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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