Sorry for the late reply and the probable break in the thread: I wasn't subscribed to the list yet (am now) and had a bit of a Windows-related problem.

On 2009-04-20 13:12:27, Vladimir Prus wrote:

> On Monday 20 April 2009 19:28:05 Ronald Landheer-Cieslak wrote: 
> > I'm trying to use Boost Build v2 on a software package that will run on 
> > Cygwin, MinGW and other platforms. On Cygwin, DLLs are installed in the bin 
> > directory and import libraries are installed in lib, and DLLs are prefixed 
> > with "cyg" and have a ".dll" extention.Boost.Buildv2 currently sees Cygwin 
> > as a UNIX platform, generates .so files and does not add the cyg prefix. 
> > Also the .so files are installed in lib, not bin (which is good for UNIX 
> > platforms). 

> can you explain the problem(s) with the current naming and placement 

> as well as why the proposed changes are the right ones. I am not saying 
> these are wrong, but Cygwin&Mingw is the constant source of confusion, 
> so it would be nice to have some background to add as comments. 

> I am sure that when I last tried, one could directly link to a shared 
> library with .so extension, without any import library. A more recent 
> comment in source has this about search paths: 

>         # windows (mingw,cygwin) -Bdynamic -lxxx 
>         # libxxx.dll.a 
>         # xxx.dll.a 
>         # libxxx.a 
>         # xxx.lib 
>         # cygxxx.dll (*) 
>         # libxxx.dll 
>         # xxx.dll 
>         # libxxx.a 

> So, it looks like you change would make Boost.Build create shared 
> libraries that cygwin linker would pick and directly link to, 
> and therefore it's not clear why import library is needed -- can you 
> clarify. 

It is possibly to link directly with a .so file, yes, but Windows doesn't know about the .so extension, so you might run into trouble when you try to run your application that's linked to the .so file. AFAICT, the Windows dynamic loader is capable of finding .so files and loading them (my test actually does work when I put the .so file next to the .exe file). Having the files named .dll is more convention that anything else. IMHO, however, following a platform's conventions for naming executables is only good manners, and (IMHO, again) Boost should be a well-behaved citizen. In any case, I do want the software I build to be well-behaved on the platforms I build them for, which means that on Darwin, they'll be called .dylib, on Windows (MinGW, Cygwin, and MSVC) they'll be called .dll and on Linux (and most other Unices) they'll be called .so.

> > The attached patch fixes the absence of the cyg prefix and has the build 
> > system generate import libraries, but does not place the DLLs in the bin 
> > directory, which I can't seem to figure out how to do. 

> Why is that required? Can 'lib' directory be added to PATH? 

In an OOTB Cygwin installation (which currently includes version 1.33.1 of Boost), lib is not in the PATH. That doesn't mean that it can't be put in there, but it would only be put in there for things built with boost-build, as other build systems either know about Cygwin or are configurable to get to know about them.

The convention on Cygwin is to have Cygwin-created DLLs start with cyg. As per the Cygwin user's guide, this is to differentiate them from native Windows DLLs (http://www.cygwin.com/cygwin-ug-net/dll.html).

As for import libraries, you can link to a DLL without them, but it generates a warning (unless you add a linker option to its command line). You only really need them of you have one DLL that links with another, that links back to your DLL. I know circular dependencies between DLLs aren't "nice", but they aren't quite forbidden either, and some-one using Boost.Build might need them for some reason. On Windows, you can't link a DLL unless all symbols in it are resolved - there can be no dangling references. Import libraries help make that possible.

There's also a (slight) efficiency issue: if the import library doesn't exist, the linker will create one from the DLL and use it in stead. All it needs to do is translate the exported symbols by prefixing _imp_, but still. Also, import libraries may actually contain code that is not in the DLL. Cygwin uses that trick itself (I don't remember what for, though) by post-processing its import library and adding a few objects to it (as import libraries are "normal" static libraries, you can do that).

And then there's the question of convention again. As DLLs should be in the PATH (actually, they have to be on Windows) and lib isn't in the path by default, but the linker does look for libraries to link for in lib, the only alternatives are:

1. putting lib in the PATH (which I'm pretty sure the Cygwin community, and especially the project leaders, would object to)

2. putting the DLLs in bin and symlinking them from lib (the other way around wouldn't work because Windows, AFAIK, doesn't follow symlinks to executables even if they are in the path, but the linker will follow symlinks to the DLLs to link with

3. create an import libary from the DLL, put it in lib and put the DLL in bin - following Cygwin conventions and being a good citizen.

Personally, I'd go for 3.

Which gets me back to my original question: regardless of whether the Boost distribution wants to take the patch I sent in or not - which you would be more than welcome to do - could some-one point me to how I can get the .dll file to be installed in bin rather than in lib?

Thanks,

Ronald

NB: as version 1.33.1 is rather out-dated, but on Cygwin, does follow the Cygwin conventions, I'd be more than happy to contribute the current version of the Boost distribution to the Cygwin distro, which I think would be a good thing for both communities. I doubt whether cygwin-apps (the group of package maintainers in Cygwin) would accept .so files in the lib directory, though.