bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15831: Absolute library paths with Cygwin + MSVC cl


From: Peter Rosin
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Date: Sat, 09 Nov 2013 02:13:50 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]