GNU bug report logs - #15831
Absolute library paths with Cygwin + MSVC cl

Previous Next

Package: libtool;

Reported by: "Tony Kelman" <kelman <at> berkeley.edu>

Date: Fri, 8 Nov 2013 04:23:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Peter Rosin <peda <at> lysator.liu.se>
To: Tony Kelman <kelman <at> berkeley.edu>, 15831 <at> debbugs.gnu.org
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Date: Sat, 09 Nov 2013 02:13:50 +0100
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





This bug report was last modified 11 years and 227 days ago.

Previous Next


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