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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
