[1.40.0] Release candidates available
The 1.40.0 release candidates are available. See http://boost.cowic.de/rc/ Please download, give it a try, and then report back either success or failures. These will get pushed out to SourceForge once we've had enough reports to be sure the packages are good. TIA, --Beman
On linux fedora F11 x86_64 I get this warning: bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage warning: ICU shared common library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. Defaulting to look for libicuuc ... LINUX warning: ICU shared data library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. 1. bjam should know to look in /usr/lib64 for all system libs 2. Is this just a harmless warning, or will the build be incorrect?
Neal Becker wrote:
On linux fedora F11 x86_64 I get this warning:
bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage
warning: ICU shared common library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. Defaulting to look for libicuuc ... LINUX warning: ICU shared data library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU.
1. bjam should know to look in /usr/lib64 for all system libs
0. I assume you meant Boost.Build? bjam is dump build engine, so it knows nothing whatsoever. 1. Could you file a bug in Trac? I don't think we can fix it right now, but we surely want to fix this for 1.41
2. Is this just a harmless warning, or will the build be incorrect?
I don't know. John? - Volodya
On linux fedora F11 x86_64 I get this warning:
bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage
warning: ICU shared common library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. Defaulting to look for libicuuc ... LINUX warning: ICU shared data library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU.
1. bjam should know to look in /usr/lib64 for all system libs 2. Is this just a harmless warning, or will the build be incorrect?
I assume that the compiler knows to look in that location? Presumably simply using: bjam -sHAVE_ICU=1 ie *without* setting ICU_PATH should just do the right thing without the warnings? ICU_PATH is there for situations where the ICU library is not already in the compiler's search paths (ie on Windows), and that shouldn't be the case on Linux. HTH John.
John Maddock wrote:
On linux fedora F11 x86_64 I get this warning:
bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage
warning: ICU shared common library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. Defaulting to look for libicuuc ... LINUX warning: ICU shared data library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU.
1. bjam should know to look in /usr/lib64 for all system libs 2. Is this just a harmless warning, or will the build be incorrect?
I assume that the compiler knows to look in that location?
Presumably simply using:
bjam -sHAVE_ICU=1
ie *without* setting ICU_PATH should just do the right thing without the warnings?
ICU_PATH is there for situations where the ICU library is not already in the compiler's search paths (ie on Windows), and that shouldn't be the case on Linux.
HTH John.
Yes, looks like -sHAVE_ICU=1 works (is this documented?)
Neal Becker wrote:
Presumably simply using:
bjam -sHAVE_ICU=1
ie *without* setting ICU_PATH should just do the right thing without the warnings?
ICU_PATH is there for situations where the ICU library is not already in the compiler's search paths (ie on Windows), and that shouldn't be the case on Linux.
HTH John.
Yes, looks like -sHAVE_ICU=1 works (is this documented?)
It's easy to check in the official docs: http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install... - Volodya
Vladimir Prus wrote:
Neal Becker wrote:
Presumably simply using:
bjam -sHAVE_ICU=1
ie *without* setting ICU_PATH should just do the right thing without the warnings?
ICU_PATH is there for situations where the ICU library is not already in the compiler's search paths (ie on Windows), and that shouldn't be the case on Linux.
HTH John.
Yes, looks like -sHAVE_ICU=1 works (is this documented?)
It's easy to check in the official docs:
http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install...
- Volodya
I must respectfully disagree. It's not easy at all. A new user would probably start with: http://www.boost.org/doc/libs/1_39_0/more/getting_started/index.html
From there quickly jump to:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html while skimming through, trying not to become frustrated with the bewildering wealth of information there, thinking "what is the damn command that is equivalent to just make?", I don't think he would ever know to look at http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install.... It certainly didn't occur to me.
I must respectfully disagree. It's not easy at all. A new user would probably start with:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/index.html
From there quickly jump to:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html
while skimming through, trying not to become frustrated with the bewildering wealth of information there, thinking "what is the damn command that is equivalent to just make?", I don't think he would ever know to look at http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install.... It certainly didn't occur to me.
Then where did you get ICU_PATH from? It's not mentioned in the getting-started guide, and the message emitted by bjam if you build without ICU support (ie by following the getting started guide) is: warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. Then this clearly directs you to the regex lib docs. But if we can do better.... ??? Regards, John.
John Maddock wrote:
I must respectfully disagree. It's not easy at all. A new user would probably start with:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/index.html
From there quickly jump to:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix- variants.html
while skimming through, trying not to become frustrated with the bewildering wealth of information there, thinking "what is the damn command that is equivalent to just make?", I don't think he would ever know to look at
http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install....
It certainly didn't occur to me.
Then where did you get ICU_PATH from? It's not mentioned in the getting-started guide, and the message emitted by bjam if you build without ICU support (ie by following the getting started guide) is:
warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature.
Then this clearly directs you to the regex lib docs. But if we can do better.... ???
Regards, John.
I see the warning does point to the regex doc page, which I somehow seemed to have not noticed (maybe a url would be nice to add). Is it possible to prominently display the typical command on common (e.g., linux) system to build with typical set of features? My first reaction, when seeing the warning that something is disabled, is to stop the build and try to figure out how to get what I'm missing (even if I don't know what it is). My reaction to seeing ICU is missing from regex is to try to fix it, because that sounds like it should be easy. I'm also warned: warning: Graph library does not contain MPI-based parallel components. My reaction is to ignore this, because: 1) I don't use MPI 2) I know MPI usually requires nontrivial work 3) I don't think I'm likely to need it So, in summary, maybe On quickstart page, somewhere prominent, a pointer that if you see the above warning #1, please refer to URL1. If you see warning #2, please refer to URL2.
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
Presumably simply using:
bjam -sHAVE_ICU=1
ie *without* setting ICU_PATH should just do the right thing without the warnings?
ICU_PATH is there for situations where the ICU library is not already in the compiler's search paths (ie on Windows), and that shouldn't be the case on Linux.
HTH John.
Yes, looks like -sHAVE_ICU=1 works (is this documented?)
It's easy to check in the official docs:
http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install...
- Volodya
I must respectfully disagree. It's not easy at all. A new user would probably start with:
Ok. It did not occur to me that you would not look at Boost.Regex docs.
http://www.boost.org/doc/libs/1_39_0/more/getting_started/index.html
From there quickly jump to:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html
while skimming through, trying not to become frustrated with the bewildering wealth of information there, thinking "what is the damn command that is equivalent to just make?", I don't think he would ever know to look at http://www.boost.org/doc/libs/1_39_0/libs/regex/doc/html/boost_regex/install.... It certainly didn't occur to me.
I agree that configuring Boost is becoming somewhat of a problem because: 1. Every library uses it's own custom convention for checking and reporting, and 2. No single document lists all the options. I actually have an action item to cleanup (1) for 1.41, and probably should address (2) as well. Does anybody have an opinion if a new section should be added to getting started, or if we need a new document "Building Boost" that describes things you find in output of "bjam --help" as well as the configuration options? - Volodya
On Wed, Aug 26, 2009 at 2:51 PM, Vladimir Prus <vladimir@codesourcery.com>wrote: 1. Every library uses it's own custom convention for checking and reporting,
and 2. No single document lists all the options.
I actually have an action item to cleanup (1) for 1.41, and probably should address (2) as well. Does anybody have an opinion if a new section should be added to getting started, or if we need a new document "Building Boost" that describes things you find in output of "bjam --help" as well as the configuration options?
Perhaps add a new "Options" section to Getting Started. I think that would be a big help. The problem with a new "Building Boost" document is that it overlaps "Getting Started" so much that (1) people won't know which doc to look in, and (2) it will cause maintenance problems in that any changes would have to be reflected in both documents. --Beman
On 08/26/2009 02:51 PM, Vladimir Prus wrote:
I agree that configuring Boost is becoming somewhat of a problem because:
1. Every library uses it's own custom convention for checking and reporting, and 2. No single document lists all the options.
This, to me, is just another indicator that boost would profit from actually treating these as separate (sub-)projects. Let users configure and build them independently, and merely provide a wrapper build script that knows about the library interdependencies, and thus can help build things in the right order (instead of having each library build assume its prerequisites were already installed. But I have been singing that song for years now, and no change is in sight. :-( Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
On 08/26/2009 02:51 PM, Vladimir Prus wrote:
I agree that configuring Boost is becoming somewhat of a problem because:
1. Every library uses it's own custom convention for checking and reporting, and 2. No single document lists all the options.
This, to me, is just another indicator that boost would profit from actually treating these as separate (sub-)projects. Let users configure and build them independently, and merely provide a wrapper build script that knows about the library interdependencies, and thus can help build things in the right order (instead of having each library build assume its prerequisites were already installed.
I fail to see how this will help. If there are 90 different documents, one for each library, possibly describing how to configure it, then users wishing to build "all of Boost" will have to read 90 different documents.
But I have been singing that song for years now, and no change is in sight. :-(
Unfortunately, you keep on saying this in so vague words, that I still don't understand what you mean. Would you mind writing down a set of concrete changes to the build process that you propose? - Volodya
On Wed, Aug 26, 2009 at 10:17 AM, Beman Dawes <bdawes@acm.org> wrote:
The 1.40.0 release candidates are available. See http://boost.cowic.de/rc/
Please download, give it a try, and then report back either success or failures.
I downloaded the Windows .7z and built it using VC++9 Express without problems. --Beman
Beman Dawes wrote:
On Wed, Aug 26, 2009 at 10:17 AM, Beman Dawes <bdawes@acm.org> wrote:
The 1.40.0 release candidates are available. See http://boost.cowic.de/rc/
Please download, give it a try, and then report back either success or failures.
I downloaded the Windows .7z and built it using VC++9 Express without problems.
To double-check -- do you have Python installed, and was Boost.Python built? We've got a report about mysterious detection failure of python with 1.39 on the users list, and I want to check if 1.40 is not affected. - Volodya
Beman Dawes wrote:
On Wed, Aug 26, 2009 at 10:17 AM, Beman Dawes <bdawes@acm.org> wrote:
The 1.40.0 release candidates are available. See http://boost.cowic.de/rc/
Please download, give it a try, and then report back either success or failures.
I downloaded the Windows .7z and built it using VC++9 Express without problems.
To double-check -- do you have Python installed, and was Boost.Python built? We've got a report about mysterious detection failure of python with 1.39 on the users list, and I want to check if 1.40 is not affected.
- Volodya
Just built with msvc 10 beta and everything built fine including boost
On Thu, Aug 27, 2009 at 12:17 AM, Vladimir Prus <vladimir@codesourcery.com>wrote: python michael
On Thu, Aug 27, 2009 at 1:17 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Beman Dawes wrote:
On Wed, Aug 26, 2009 at 10:17 AM, Beman Dawes <bdawes@acm.org> wrote:
The 1.40.0 release candidates are available. See http://boost.cowic.de/rc/
Please download, give it a try, and then report back either success or failures.
I downloaded the Windows .7z and built it using VC++9 Express without problems.
To double-check -- do you have Python installed,
Yes.
and was Boost.Python built?
Yes.
We've got a report about mysterious detection failure of python with 1.39 on the users list, and I want to check if 1.40 is not affected.
Looks good here. This was Windows XP, SP 3. --Beman
participants (6)
-
Beman Dawes -
John Maddock -
Michael Mathews -
Neal Becker -
Stefan Seefeld -
Vladimir Prus