Re: [Boost-build] Cygwin DLLs not named properly and installed in the right location

Subject: Re: [Boost-build] Cygwin DLLs not named properly and installed in the right location
From: Ronald Landheer-Cieslak (rlc_at_[hidden])
Date: 2009-05-06 21:59:23

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.