Build process doesn't generate DLL import libs on Cygwin

[wilx]

The Boost.Build process doesn't generate any import
libraries for DLLs. This is the relevant part of my
build script on Cygwin:

build_opts="release <runtime-link>static/dynamic
<threading>multi"
./tools/build/jam_src/bin.cygwinx86/bjam -d3 \
        -sTOOLS=gcc \
        -sBUILD="${build_opts}" \
        -sPYTHON_VERSION="${python_ver}" \
        --builddir=./build-gcc \
        --stagedir=./stage-gcc \
        --prefix="${install_dir}/usr" \
        --sysconfdir="${install_dir}/etc" \
        --libexecdir="${install_dir}/usr/sbin" \
        --localstatedir="${install_dir}/var" \
        --datadir="${install_dir}/usr/share" \
        --mandir="${install_dir}/usr/share/man" \
        --infodir="${install_dir}/usr/share/info" \
        --without-test \
        --layout=versioned \
        install

[david_abrahams]

Logged In: YES 
user_id=52572

As far as we know, cygwin shared libs don't need import
libraries.  If you build with the gcc toolset from a regular
windows build of bjam, you will get import libraries.

I've closed this issue and marked it as invalid but if you
disagree, feel free to reopen it.

[wilx]

Logged In: YES 
user_id=5676

I do not know how else to link to .dll then using an import
library.
I think that /lib full of libfoo.dll.a files supports my
opinion too.

[wilx]

Logged In: YES 
user_id=5676

Ok, I have tried it and it indeed works without the import
libs. Even when it does I see a problem there. First let me
explain something.

Cygwin prefixes its .dlls with cyg- prefix and puts them in
/bin. However it might seem strange or stupid to anybody
with background in *nix, this is the way it is. The .dlls
are in /bin because /bin is in PATH and the .dlls have to be
in PATH to be reachable. On *nix systems the /lib dirs are
not in PATH so adding it into PATH would create another
difference between other *nix systems and Cygwin.

On the other hand, putting the Boost's .dlls into /bin
without import libraries in /lib forces everybody to add -L
/bin to their compilation which is weird/non-standard too.

Knowing all this, it seems that the best solution for Boost
on Cygwin would be for Boost.Build to generate import libs
into /lib and .dlls with cyg- prefix (e.g.
cygboost_filesystem-gcc-mt-1_33.dll) into /bin.

The reason why I bother you with all this is that I want to
package Boost into Cygwin package. I would have made the
changes locally already if I knew how to do it.
Unfortunatelly Boost.Build and BJam is totally opaque for me.

[david_abrahams]

Logged In: YES 
user_id=52572

We decided this isn't a bug.  If it is actually impossible
to create Cygwin packages without import libraries, we
should reconsider.  If it's possible to merely add aliases
in /lib to the .dlls which are in /bin, that would seem
reasonable.

[wilx]

Logged In: YES 
user_id=5676

I suppose that it could work. But it goes against the
directory layout all other Cygwin packages use.

[wilx]

Logged In: YES 
user_id=5676
Originator: YES

Just for the record. Latest Cygwin Boost package contains .dlls built in the way it is acceptable for Cygwin package, not the way Boost build process provides. I had to employ two hacks to the build system. Patches agains 1.33.1 attached.

File Added: allyourbase.jam.patch

[wilx]

Logged In: YES 
user_id=5676
Originator: YES

File Added: gcc-tools.jam.patch

[david_abrahams]

Logged In: YES 
user_id=52572
Originator: NO

It's not clear whether these issues exist in BBv2.  If anything should be done about it, it should be done there, since V1 is officially retired.  Please work with Vladimir Prus to figure out whether something needs to be done.  Thanks,

Dave