[Boost-bugs] [Boost C++ Libraries] #1177: Various bugs in STLport jamfile

Subject: [Boost-bugs] [Boost C++ Libraries] #1177: Various bugs in STLport jamfile
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-08-13 22:13:45

#1177: Various bugs in STLport jamfile
 Reporter: ddeakins_at_[hidden] | Owner: vladimir_prus
     Type: Patches | Status: new
Milestone: To Be Determined | Component: build
  Version: Boost 1.34.1 | Severity: Problem
 Keywords: |
 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:


 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

 then I get a build path that looks like this:


 (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.

Ticket URL: <http://svn.boost.org/trac/boost/ticket/1177>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:56 UTC