Various bugs in STLport jamfile

[ddeakins@…]

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.

[ddeakins@…]

I tried to attach a .patch file, but Trac said it was spam and blocked it. Please see my 13 Aug 2007 post to the boost.build list for the patch file.

[ddeakins@…]

Patch for stlport.jam

[ddeakins@…]

Some additional changes were required to stlport.jam to account for new work done in builtin.jam. There was also a small flaw in the previous patch related to checking feature <link> vs. feature <runtime-link>. Please use the attached patch file in place of any earlier ones.

[Vladimir Prus]

(In [39645]) STLPort improvements:

• Add _static in library name as necessary
• Define _STLP_USE_DYNAMIC_LIB depending on <runtime-link>, not <runtime-debugging>

Patch from David Deakins. Addresses #1177.

[Vladimir Prus]

David, I have applied your patches, with various tweaks

1. Instead of adding .lib in stlport, I have changes msvc not do remove existing suffix. It's better, because your code for adding .lib breaks linux.
2. Your analysis of duplicate element in target path is absolutely correct. However, the code in question was trying to use non-free usage requirements which is not supported now, and I've just removed that code.

Can you check that the current version works for you?

[ddeakins@…]

Interestingly with your changes applied, I am now seeing libraries like 'stlportstld.5.1.lib.lib' during the link step. It appears that the items in FINDLIBS_ST and FINDLIBS_SA now have the .lib extension already (which was not the case at some point in the past). So I think we want to revert the change to msvc.jam.

[ddeakins@…]

After further evaluation, the .lib.lib problem was coming from an issue with our test configuration, not from the new jam files. After fixing this problem, it appears that the changes are working correctly. This ticket can be closed.

[Vladimir Prus]

Closing. Thanks for investigating the issue and providing the patch!