[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-build
Subject:    Re: [Boost-build] [Boost-testing] [wave] [date_time] bjam --v2
From:       "Reece Dunn" <msclrhd () hotmail ! com>
Date:       2006-06-25 0:23:14
Message-ID: BAY115-W2040B11AA84E2FA12C555A0780 () phx ! gbl
[Download RAW message or body]

Hartmut Kaiser wrote:
> Reece Dunn wrote:
> 
> > There are currently some issues when running:
> > 
> >    bjam --v2 install msvc-7.1 # [1]
> > 
> > and
> > 
> >    bjam --v2 install msvc-7.1 link=static,shared # [2]
> > 
> > These were identified in the "[Boost-build] boost.build v2 
> > and toolset="
> > discussion on the boost.build mailing list.
> > 
> > Running [1] highlights a problem with Boost.Wave. Since wave 
> > adds <rtti>off for msvc-7.1, this is causing problems when it 
> > is pulling in Boost.FileSystem. The <tag> rule is using the 
> > <rtti>on version of filesystem, not the <rtti>off version, so 
> > BBv2 ends up trying to create two versions of 
> > boost_filesystem-vc71-mt-gd-1_35.lib.
> > 
> > The workaround is to open the following files:
> > 
> >     $(BOOST_ROOT)/tools/wave/build/Jamfile.v2
> >     $(BOOST_ROOT)/libs/wave/build/Jamfile.v2
> > 
> > and comment out the line:
> > 
> >      <toolset-msvc:version>7.1:<rtti>off   # workaround for 
> > compiler bug
> > 
> > in each, however this is not an ideal solution :(!
> 
> If you do that, the build will fail because of the mentioned compiler bug.

Hence it being a workaround to the install issue.

> The only way is to accept to get two different versions of the libraries.

Agreed.

> What perhaps needs to be done is to code the rtti settings into the library
> names.

Thanks! Your hint lead to a solution that works for:

   bjam --v2 install msvc-7.1 link=static,shared

The Wave/FileSystem issue is solved by adding 'r' when rtti=on.

The DateTime issue is a more global one relating to building link=static
and link=share at the same time. The msvc compiler produces a LIB
file in both these cases (static produces a STATIC_LIB target and
share produces an IMPORT_LIB target). These targets clash, hence
the error.

The solution I have gone for is to add "-imp" for IMPORT_LIB targets.
Therefore, link=static will produce:

   boost_date_time-***.lib

and link=share will produce:

   boost_date_time-***-imp.lib
   boost_date_time-***.dll

This causes the above install to work. I haven't done extensive
testing, just the above. If this is approved, I will commit it.

NOTE: I don't know about other combinations.

- Reece
_________________________________________________________________
Try Live.com: where your online world comes together - with news, sports, weather, and much more.
http://www.live.com/getstarted
["stage.jam.patch" (application/octet-stream)]

Index: tools/build/v2/tools/stage.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/v2/tools/stage.jam,v
retrieving revision 1.75
diff -u -r1.75 stage.jam
--- tools/build/v2/tools/stage.jam	21 Feb 2006 13:08:51 -0000	1.75
+++ tools/build/v2/tools/stage.jam	25 Jun 2006 00:03:59 -0000
@@ -485,6 +485,7 @@
         local runtime-tag = ;
         if <runtime-link>static in $(properties) { runtime-tag += s ; }
         if <runtime-debugging>on in $(properties) { runtime-tag += g ; }
+        if <rtti>on in $(properties) { runtime-tag += r ; }
         
         if <variant>debug-python in $(properties) { runtime-tag += y ; }
         if <variant>debug in $(properties) { runtime-tag += d ; }
@@ -534,6 +535,11 @@
         tags += $(thread-tag:J=) ;
         tags += $(runtime-tag:J=) ;
         #tags += $(version-tag) ;
+
+        if [ type.is-derived $(type) IMPORT_LIB ]
+        {
+            tags += imp ;
+        }
     
         local result ;
         
@@ -545,6 +551,7 @@
         {
             result = $(name) ;
         }
+
         return [ virtual-target.add-prefix-and-suffix $(result) : $(type) 
           : $(property-set) ] ;
     }    


[prev in list] [next in list] [prev in thread] [next in thread]