Re: [boost] [RC_1_34_0] MSVC 8.0 link looking for lib*
Rene Rivera wrote:
It's yet another discrepancy between the BBv1 and BBv2 build files. Which I guess I'll have to fix. Incidentally I had also just noticed that problem when I was trying to solve the first discrepancy :-)
BBv2 also chokes when doing: bjam --v2 install msvc-7.1 link=static,shared I have posted this (with a proposed solution several times), but haven't had a response. The problem is two-fold: (1) The stage.jam tag rule doesn't propagate the <rtti> option which Boost.Wave turns of, causing a duplicate target for Boost.FileSystem. Adding 'r' for rtti=on solves this issue. This will produce: boost_filesystem-vc71-gd-r.lib boost_filesystem-vc71-gd.lib (2) Again in the stage rule, link=shared generates an IMPORT_LIB target that conflicts with the STATIC_LIB target generated by link=static. Adding 'i' or '-imp' for IMPORT_LIB fixes this issue. This will produce (with rtti=on above): boost_filesystem-vc71-gd-ri.lib boost_filesystem-vc71-gd-r.dll or boost_filesystem-vc71-gd-r-imp.lib boost_filesystem-vc71-gd-r.dll However, before committing the patch (available from by "bjam install issues" post) I want to see if this is the right solution. - Reece _________________________________________________________________ Be one of the first to try Windows Live Mail. http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-491...
Reece Dunn wrote:
Rene Rivera wrote:
It's yet another discrepancy between the BBv1 and BBv2 build files. Which I guess I'll have to fix. Incidentally I had also just noticed that problem when I was trying to solve the first discrepancy :-)
BBv2 also chokes when doing:
bjam --v2 install msvc-7.1 link=static,shared
I have posted this (with a proposed solution several times), but haven't had a response.
Yea, noticed :-) Just hadn't had a chance to think about it yet.
(1) The stage.jam tag rule doesn't propagate the <rtti> option which Boost.Wave turns of, causing a duplicate target for Boost.FileSystem. Adding 'r' for rtti=on solves this issue. This will produce:
boost_filesystem-vc71-gd-r.lib boost_filesystem-vc71-gd.lib
I don't think this is the right solution for this problem. Although it might be a solution for people who turn off rtti overall. If I remember from previous discussions we don't want to encourage turning off what are supposed to be standard features of the language. And for that matter have to test such variants. There's also the problem of changing the auto-link code to account for these new names. So it's not just a matter of changing the jam code. That means that since we are not adding new features to code anymore we can't change the auto-link code to account for those new names. Personally I think turning off rtti for the whole wave library to workaround a vc71 bug is the wrong solution, read that as it's a kludge. So I would consider it a bug in wave that needs to get fixed.
(2) Again in the stage rule, link=shared generates an IMPORT_LIB target that conflicts with the STATIC_LIB target generated by link=static. Adding 'i' or '-imp' for IMPORT_LIB fixes this issue.
This I will fix by making it behave as BBv1 does, and what is documented, and what the auto-link code expects of using the "lib" prefix. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Personally I think turning off rtti for the whole wave library to workaround a vc71 bug is the wrong solution, read that as it's a kludge. So I would consider it a bug in wave that needs to get fixed.
Hmmm, I tend to disagree here. It's a really dumb compiler bug showing up because of code complexity, where I'm not able to simplify the code without rewriting parts of the lib. If it were possible to switch of rtti during the compilation of parts of the Wave lib files _only_ (without propagating this to the dependent libraries) the bug would be fixable a lot easier, since mixing RTTI and non-RTTI code is possible w/o problems in VC7.1. Regards Hartmut
Hartmut Kaiser wrote:
Rene Rivera wrote:
Personally I think turning off rtti for the whole wave library to workaround a vc71 bug is the wrong solution, read that as it's a kludge. So I would consider it a bug in wave that needs to get fixed.
Hmmm, I tend to disagree here. It's a really dumb compiler bug showing up because of code complexity, where I'm not able to simplify the code without rewriting parts of the lib.
If it were possible to switch of rtti during the compilation of parts of the Wave lib files _only_ (without propagating this to the dependent libraries) the bug would be fixable a lot easier, since mixing RTTI and non-RTTI code is possible w/o problems in VC7.1.
Done. I changed the Jamfile.v2 so that RTTI is turned off only when building the individual object files not when linking the library, nor when linking to other libraries (i.e. filesystem). A better solution would be a pragma in the sources, as that would also account for when users don't use Boost.Build and build the files directly. But I don't know if an RTTI pragma exists. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Done. I changed the Jamfile.v2 so that RTTI is turned off only when building the individual object files not when linking the library, nor when linking to other libraries (i.e. filesystem).
PS. I also put back in the disabling of warnings for the cpp_re source that was present in BBv1. But I noticed that other files generate warnings. So you might want to look at those and perhaps add to the list of sources to disable warnings for. Of course, again, accounting for such things in code is better as it doesn't rely on Boost.Build. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Personally I think turning off rtti for the whole wave library to workaround a vc71 bug is the wrong solution, read that as it's a kludge. So I would consider it a bug in wave that needs to get fixed.
Hmmm, I tend to disagree here. It's a really dumb compiler bug showing up because of code complexity, where I'm not able to simplify the code without rewriting parts of the lib.
If it were possible to switch of rtti during the compilation of parts of the Wave lib files _only_ (without propagating this to the dependent libraries) the bug would be fixable a lot easier, since mixing RTTI and non-RTTI code is possible w/o problems in VC7.1.
Done. I changed the Jamfile.v2 so that RTTI is turned off only when building the individual object files not when linking the library, nor when linking to other libraries (i.e. filesystem).
Thanks! I'm going to update the other Jamfile.v2's asap.
A better solution would be a pragma in the sources, as that would also account for when users don't use Boost.Build and build the files directly. But I don't know if an RTTI pragma exists.
Unfortunately such a #pragma doesn't exist (to the best of my knowledge). Regards Hartmut
participants (3)
-
Hartmut Kaiser -
Reece Dunn -
Rene Rivera