[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Favoring static linking at configure time
From: |
Peter Rosin |
Subject: |
Re: Favoring static linking at configure time |
Date: |
Mon, 17 Dec 2007 09:09:06 +0100 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
On Sun, Dec 16, 2007 at 11:41:20PM +0100, Benoit Sigoure wrote:
> On Dec 16, 2007, at 7:56 PM, Peter Rosin wrote:
>
> >On Sun, Dec 16, 2007 at 04:23:41PM +0100, Benoit Sigoure wrote:
> >>OK So finally I solved the whole thing by adding /abs/path/to/libfoo.
> >>$libext (instead of -lfoo) in $LIBS ($libext is computed by libtool,
> >>most of the time it's .a but it happens to be .lib at least for
> >>MSVC). This is probably fragile but at least it works on GNU/Linux
> >>(GCC, ICC), OSX (Apple GCC) and Windows (Cygwin, MinGW, MSVC).
> >
> >It is fragile. There are several ways to use MSVC with libtool. The
> >patches I have worked on does not name the static library according
> >to your pattern, so your scheme would break with them.
> >
> >I don't know if you care though...
>
> I do care but I'm trying to find a good compromise between simplicity
> of the code and its portability. Moreover, the fact your patches
> lead to different names is irrelevant here, since I'm in a situation
> where I only check for Boost libraries (my macros are Boost specific)
> and Boost doesn't use Libtool so it won't follow your naming scheme.
And Boost doesn't use libtool for its build, right?
> Just out of curiosity, how are named the libraries with your patches?
The problem is of course that you need three files on windows, and
I have settled on naming them:
* shared: foo-2.dll
* import: foo.lib
* static: foo-2.lib
(where 2 is the major version of the library)
>From one point of view, the static lib should be named foo.lib,
since that's how things look on most platforms (well, s/\.lib/.a/
but you get my point...). But from another point of view, the
Microsoft linker doesn't have a -l option, and the closest one
gets instead of -lfoo is foo.lib. I have settled for making the
shared build the default when you say foo.lib, since I think
this is what most people from the Windows camp expect from when
they say foo.lib to the linker.
Cheers,
Peter
- Re: Favoring static linking at configure time, (continued)
- Re: Favoring static linking at configure time, Brian Dessent, 2007/12/04
- Re: Favoring static linking at configure time, Ralf Wildenhues, 2007/12/04
- Re: Favoring static linking at configure time, Benoit Sigoure, 2007/12/16
- Re: Favoring static linking at configure time, Peter Rosin, 2007/12/16
- Re: Favoring static linking at configure time, Benoit Sigoure, 2007/12/16
- Re: Favoring static linking at configure time,
Peter Rosin <=
- Re: Favoring static linking at configure time, Benoit Sigoure, 2007/12/19
- Re: Favoring static linking at configure time, Peter O'Gorman, 2007/12/04
- Re: Favoring static linking at configure time, Benoit Sigoure, 2007/12/04
- Re: Favoring static linking at configure time, Peter O'Gorman, 2007/12/04