The current ebuild for the boost library uses the USE=icc flag to configure building the libraries with the Intel compiler rather than GCC. It does not, however, allow to build the libraries with _both_ compilers, something the boost build system can do. Just build the library with: bjam -q --v2 toolset=gcc,icc threading=multi,single variant=debug,release The '-q' flag will tell jam to abort compilation on error. This may apply to bug #76466. Reproducible: Always Steps to Reproduce: 1. 2. 3.
i was wondering how long till someone who wants both finds me ;), i'll be off from 5/6/05 to 5/19/05, so if this is not resolved by friday, expect it to go slow from there, basically this is just a heads up i have not seen this way to install before, as you might have seen i achieve the same with -sBUILD (which is what i got from the docs) what i find rather troubling is if we build with the toolset name in the library names we will have both -icc- and -gcc- flavors installed, would you agree that who wants both toolset names will NOT want the toolset free library names as often requested? just to know how to deal with the links created as boost is built now w/o the -toolset- name and links created with them we would need USE=icc and USE=icconly (im open for other suggestions on the second name) other comments/suggestions welcome
I think the toolset-free library names should still be installed. GCC and ICC libraries are interchangeable (unless explicitely disabled), so if you don't care which version you get you can just link "-lboost_threads" and expect the result to work. Or maybe USE=install-defaultversions (or something like that) is the way to go? Although personally I'm not a huge fan of lots and lots of USE flags. Anyway, it's not an urgent matter, so enjoy your vacation by all means. ;-) I was merely trying to set things in motion in time for the upcoming boost 1.33 release.
my goal is to have boost be appealing to as many users as possible, making gento interesting not only for those who get it due to some app they use needing it, but also for those who wish to develop with it, my ue of boost is limited to some of the headers, which is why the lack of bjam didnt appear strange to me in the least im hoping to have 1.32.0-rX to be a perfect base for 1.33.0, using mostly only boost.build parts should make this rather easy as to links when both icc and gcc is used, im really not sure if they make sense considering the special clientel who would be using both at once and them wanting to control if they link against icc or gcc anyway? ill be thinking about that, i dont know if i want another USE flag, soon boost will look like mplayer ;) USE=install-defaultversions would be particularly troubling considering having the toolset name is default and w/o them boost requiring an additonal -layout=system thanks for your input, nice to see interest in boost
Version 1.33 has been released now. Any chance you'll have the time to complete this EBUILD soon?
due to lack of support for icc in gentoo i decided to deprecate icc support for boost as of 1.33.0-r1
