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: "Tony Kelman" <kelman <at> berkeley.edu>
To: "Peter Rosin" <peda <at> lysator.liu.se>, <15831 <at> debbugs.gnu.org>
Subject: bug#15831: Absolute library paths with Cygwin + MSVC cl
Date: Fri, 8 Nov 2013 19:12:15 -0800
> 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





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.