id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1177	Various bugs in STLport jamfile	ddeakins@…	Vladimir Prus	"I was testing BBv2 from 1.34.1 on some of my builds that use STLport
and I ran across a few small issues. These tests were all on a WinXP
machine and I was using STLport 5.1.3 with VC8 and VC8 cross-compiling
for Windows CE 5.0/x86.

1) In line 223 of stlport.jam, runtime-debugging=on is checked to decide
whether <define>_STLP_USE_DYNAMIC_LIB=1 should be added to the usage
requirements. Based on what that flag means and also on the comments in
the header of stlport.jam, it seemed like link=shared should be checked
here (rather than runtime-debugging=on).

2) When building libraries with STLport 5.1 and using link=shared and
runtime-link=shared, the link.dll action was failing with

   LINK : fatal error LNK1181: cannot open input file 'stlportstld.5.lib'

The STLport 5.x libraries use names like stlportxxx.5.x.lib. The
stlport.jam file correctly reflects this v5 naming convention (lines
130-143), but the .1 in stlportstld.5.1 was getting dropped before the
library name shows up the link RSP file. After some investigation, it
appears that this is occurring in msvc.jam in line 738 where libraries
are added to the link RSP file with the expression:

   $(FINDLIBS_ST:S=.lib)

The :S= modifier is treating the .1 in stlportstd.5.1 as a suffix and
dutifully removing it. It seems like this can be fixed by either
removing the :S= modifier in msvc.jam or adding a .lib in stlport.jam.
I wasn't clear to me which method is preferred.

3) Since I compile different builds of the STLport libraries for
vc8-win32 and vc8-winCE-x86, my user-config.jam up is set up like so:

  using stlport : 5.1~vc8 : C:/STLPort/STLPort-5.1.3/stlport
                            C:/STLPort/STLPort-5.1.3/lib/vc8 ;
  using stlport : 5.1~evc8~x86 : C:/STLPort/STLPort-5.1.3/stlport
                                 C:/STLPort/STLPort-5.1.3/lib/evc8-x86 ;

When I specify a specific version of stlport in my build request such as:

bjam --v2 --prefix=C:\Boost --with-signals debug
msvc/threading=multi/link=shared/runtime-link=shared/stdlib=stlport-5.1~vc8
install

then I get a build path that looks like this:

C:\CVS\Boost_1_34_1\boost\bin.v2\libs\signals\build\msvc-8.0\debug
\stdlib-stlport-5.1~vc8\stdlib-stlport-5.1~vc8\threading-multi

(Note that 'stdlib-stlport-5.1~vc8' is repeated twice.)

This is a small issue, but I spent a little bit of time looking into it.
  Apparently the duplication comes from line 260 in stlport.jam where
<stdlib>stlport-$(self.version) is added to the usage requirements when
a specific STLport version is requested (as opposed to just
<stdlib>stlport getting added when only a single version of STLport is
available). At the time when Boost.Build merges the STLport usage
requirements with the properties in the original build request, the
<stdlib>stlport-5.1~vc8 property from the build request has been split
into <stdlib>stlport and <stdlib-stlport:version>5.1~vc8 properties. As
a result, the usage requirement for <stdlib>stlport-5.1~vc8 specified on
line 260 of stlport.jam does not seem to get filtered out as a
duplicate. So then later on when <stdlib>stlport and
<stdlib-stlport:version> are back as a single propery and the build path
is created, <stdlib>stlport-5.1~vc8 ends up being in the property set
twice and causes the duplication in the directory structure. In my
tests, if line 259-260 of stlport.jam are changed to:

  usage-requirements +=
     <stdlib>stlport <stdlib-stlport:version>$(self.version) ;

then the duplication is eliminated. However, I'm certainly not a
Boost.Build expert and I may be missing something or there may be a
better solution. "	Patches	closed	To Be Determined	build	Boost 1.34.1	Problem	fixed