I was testing BBv2 from RC_1_34_0 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 RC2 with VC8 and VC8
cross-compiling
for Windows CE 5.0/x86. If these issues have already been
mentioned
previously, please forgive my duplication:
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.1RC2/stlport
C:/STLPort/STLPort-5.1RC2/lib/vc8 ;
using stlport : 5.1~evc8~x86 :
C:/STLPort/STLPort-5.1RC2/stlport
C:/STLPort/STLPort-5.1RC2/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:CVSBoost_1_34_0boostbin.v2libssignalsbuildmsvc-8.0
debug
stdlib-stlport-5.1~vc8stdlib-stlport-5.1~vc8threading-mul
ti
(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.
Thanks for your help,
-Dave
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|