1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. Thanks, --Beman
Beman Dawes wrote, On 10.8.2009 17:50:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. It builds on Cygwin 1.5 with GCC 4.3 if I just choose release variant. --build-type=complete fails:
amber2::wilx:~/tmp/boost_1_40_0_beta1> nice -n 20 ./bjam -d+2 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib toolset=gcc-4.3 --without-mpi stage --layout=versioned --build-type=complete Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use -- VH
Václav Haisman wrote:
Beman Dawes wrote, On 10.8.2009 17:50:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. It builds on Cygwin 1.5 with GCC 4.3 if I just choose release variant. --build-type=complete fails:
Why do you want --build-type=complete?
amber2::wilx:~/tmp/boost_1_40_0_beta1> nice -n 20 ./bjam -d+2 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib toolset=gcc-4.3 --without-mpi stage --layout=versioned --build-type=complete Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use
Hmm, ICU's acting up again. John, this seems to become a recurring issue. Can you suggest some alternative behaviour I should implement? - Volodya
amber2::wilx:~/tmp/boost_1_40_0_beta1> nice -n 20 ./bjam -d+2 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib toolset=gcc-4.3 --without-mpi stage --layout=versioned --build-type=complete Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use
Hmm, ICU's acting up again.
John, this seems to become a recurring issue. Can you suggest some alternative behaviour I should implement?
This is because he's asked for runtime-link=static in combination with ICU? In that case the targets that depend upon that "impossible" combination should not be built, but everything else should be? John.
John Maddock wrote:
amber2::wilx:~/tmp/boost_1_40_0_beta1> nice -n 20 ./bjam -d+2 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib toolset=gcc-4.3 --without-mpi stage --layout=versioned --build-type=complete Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use
Hmm, ICU's acting up again.
John, this seems to become a recurring issue. Can you suggest some alternative behaviour I should implement?
This is because he's asked for runtime-link=static in combination with ICU?
In that case the targets that depend upon that "impossible" combination should not be built, but everything else should be?
Hmm, isn't it just boost.regex? Or there are other targets that depend on that? Do you want some diagnostic, or silent skipping? - Volodya
This is because he's asked for runtime-link=static in combination with ICU?
In that case the targets that depend upon that "impossible" combination should not be built, but everything else should be?
Hmm, isn't it just boost.regex? Or there are other targets that depend on that? Do you want some diagnostic, or silent skipping?
Yes I believe it's just regex in this case (unless there are any other libraries that depend upon external C++ .so's?), a warning to the effect that one particular combination can't be built would be fine. If this can be fixed easily in the regex Jamfile then that's fine too. John.
Vladimir Prus wrote:
Václav Haisman wrote:
Beman Dawes wrote, On 10.8.2009 17:50:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. It builds on Cygwin 1.5 with GCC 4.3 if I just choose release variant. --build-type=complete fails:
Why do you want --build-type=complete?
It doesn't and shouldn't matter what the answer to that question is. Whether it's because someone is not sure what they want yet so want all variant, or they generally have a need for all variant. It's a common and basic option, if you want to build all supported version pass --build-type=complete. I think it actually say something along that line in the docs. The user shouldn't have to worry about the details. That's the whole point of having a catch all option instead of making users specify each and every variant separately.
amber2::wilx:~/tmp/boost_1_40_0_beta1> nice -n 20 ./bjam -d+2 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib toolset=gcc-4.3 --without-mpi stage --layout=versioned --build-type=complete Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use
Hmm, ICU's acting up again.
John, this seems to become a recurring issue. Can you suggest some alternative behaviour I should implement?
Well, it's the same issue as before. Either, the static combination with ICU that causes the conflict should not be built, or the static combination should be built without linking to ICU. With or without a warning message to the user and documentated in docs. KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
Beman Dawes wrote:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems.
FWIW, I have tried on Linux, with both stage and install, and with both --layout=system, and --layout=versioned, and things worked OK. --build-type=complete does not work with ICU installed in the same way as reported by Václav Haisman. It would be important to have somebody to test on Windows, using the "bootstrap.bat + .\bjam" procedure. I can do this, but not sooner than Saturday. - Volodya
Vladimir Prus wrote:
Beman Dawes wrote:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems.
FWIW, I have tried on Linux, with both stage and install, and with both --layout=system, and --layout=versioned, and things worked OK.
--build-type=complete does not work with ICU installed in the same way as reported by Václav Haisman.
It would be important to have somebody to test on Windows, using the "bootstrap.bat + .\bjam" procedure. I can do this, but not sooner than Saturday.
BTW, can the calendar at http://www.boost.org/development/index.html be updated, so that everybody have a clear picture on target dates? Thanks, Volodya
On Wed, Aug 12, 2009 at 9:52 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Beman Dawes wrote:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems.
FWIW, I have tried on Linux, with both stage and install, and with both --layout=system, and --layout=versioned, and things worked OK.
--build-type=complete does not work with ICU installed in the same way as reported by Václav Haisman.
It would be important to have somebody to test on Windows, using the "bootstrap.bat + .\bjam" procedure. I can do this, but not sooner than Saturday.
Hi, this is my first post to the ml, so I picked up a relatively easy task :-) I have built the boost-windows-2009-08-11 rc without any glaring errors, with visual studio 2010 beta1. I simply did, from a visual studio 2010 prompt, bootstrap bjam.exe --toolset=msvc-10.0 --build-type=complete >build_complete.log 2>&1 The resulting project -config.jam was very simple, just one line with using msvc ; The last line of the log are the following: ...failed updating 6 targets... ...skipped 22 targets... ...updated 2199 targets... I don't have time at the moment to run some regression tests. I began following the procedure indicated on the docs but I found some minor typos which slowed me, and now I'm late. It seems to me that, without any tuning, there is some slightly misplaced path (for instance, this is the output that I am getting C:\libs\boost-windows-2009-08-11\libs\regex\test>..\..\..\tools\regression\src\library_test --toolset=msvc-10.0 boost_root: C:/libs/boost-windows-2009-08-11 locate_root: C:/libs/boost-windows-2009-08-11 **** exception(205): std::runtime_error: boost::filesystem::basic_directory_iterator constructor: The system cannot find the path specified: "C:\libs\boost-windows-2009-08-11\bin.v2\libs\regex\test" ******** errors detected; see standard output for details ******** And this is only natural, since vin.v2\libs\regex doesn't contain any test folder, while on the contrary . Am I doing something wrong? If needed I can attach the build log. Hope to have been of some help. bye, Francesco ps: the two small typos in the docs are the following: 1) in the Generating library status page (boost-windows-2009-08-11\tools\regression\doc\library_status.html), the path to library_test.bat is ..\..\..\tools\regression\src\library_test and not ..\..\..\tools\regression\library_test. 2) another small glitch is that the Jamroot.jam didn't build the library_status.exe. I added a #~ just before "explicit library_status;" and it built, but contrarily to status.html indications both process_jam_log.exe and library_status.exe were to be found in a subdir of the bin\ folder (in my case they were to be found under boost-windows-2009-08-11\tools\regression\build\bin\msvc-10.0\release\threading-multi )
Francesco Guerrieri wrote:
On Wed, Aug 12, 2009 at 9:52 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Beman Dawes wrote:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems.
FWIW, I have tried on Linux, with both stage and install, and with both --layout=system, and --layout=versioned, and things worked OK.
--build-type=complete does not work with ICU installed in the same way as reported by Václav Haisman.
It would be important to have somebody to test on Windows, using the "bootstrap.bat + .\bjam" procedure. I can do this, but not sooner than Saturday.
Hi, this is my first post to the ml, so I picked up a relatively easy task :-) I have built the boost-windows-2009-08-11 rc without any glaring errors, with visual studio 2010 beta1.
I simply did, from a visual studio 2010 prompt,
bootstrap bjam.exe --toolset=msvc-10.0 --build-type=complete >build_complete.log 2>&1
The resulting project -config.jam was very simple, just one line with
using msvc ;
The last line of the log are the following: ...failed updating 6 targets... ...skipped 22 targets... ...updated 2199 targets...
Hmm. Can you run the same command again, and post the error messages? It seems like some libraries does not work with msvc 10.0.
I don't have time at the moment to run some regression tests. I began following the procedure indicated on the docs but I found some minor typos which slowed me, and now I'm late. It seems to me that, without any tuning, there is some slightly misplaced path (for instance, this is the output that I am getting C:\libs\boost-windows-2009-08-11\libs\regex\test>..\..\..\tools\regression\src\library_test --toolset=msvc-10.0 boost_root: C:/libs/boost-windows-2009-08-11 locate_root: C:/libs/boost-windows-2009-08-11
**** exception(205): std::runtime_error: boost::filesystem::basic_directory_iterator constructor: The system cannot find the path specified: "C:\libs\boost-windows-2009-08-11\bin.v2\libs\regex\test" ******** errors detected; see standard output for details ********
And this is only natural, since vin.v2\libs\regex doesn't contain any test folder, while on the contrary .
Am I doing something wrong?
If needed I can attach the build log. Hope to have been of some help.
bye, Francesco ps: the two small typos in the docs are the following: 1) in the Generating library status page (boost-windows-2009-08-11\tools\regression\doc\library_status.html), the path to library_test.bat is ..\..\..\tools\regression\src\library_test and not ..\..\..\tools\regression\library_test. 2) another small glitch is that the Jamroot.jam didn't build the library_status.exe. I added a #~ just before "explicit library_status;" and it built, but contrarily to status.html indications both process_jam_log.exe and library_status.exe were to be found in a subdir of the bin\ folder (in my case they were to be found under boost-windows-2009-08-11\tools\regression\build\bin\msvc-10.0\release\threading-multi )
Hmm, why do you actually need that? What docs are you reading? I think the procedure involving run.py does not use those tools at all. Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Vladimir Prus-3 wrote:
It seems like some libraries does not work with msvc 10.0.
I think the program options lib fails to build with VC10 beta 1 (due to a bug in the beta). -- View this message in context: http://www.nabble.com/-1.40.0--Beta-1-release-candidate-available-tp24902288... Sent from the Boost - Dev mailing list archive at Nabble.com.
I could pin down the filesystem problem. It is actually a scoped enum problem The reason is a macro definition in the system header <rpc/ types.h>, which defines #define enum_t int Changing the order of include files solves the problem in my current codes, but probably the scoped enum should take care of this conflict. Matthias
Matthias Troyer wrote:
I could pin down the filesystem problem. It is actually a scoped enum problem The reason is a macro definition in the system header <rpc/ types.h>, which defines
#define enum_t int
Changing the order of include files solves the problem in my current codes, but probably the scoped enum should take care of this conflict.
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Did someone open a ticket for this?
Richard Webb wrote:
Vladimir Prus-3 wrote:
It seems like some libraries does not work with msvc 10.0.
I think the program options lib fails to build with VC10 beta 1 (due to a bug in the beta).
(thats a bug in the msvc beta, not the boost beta). -- View this message in context: http://www.nabble.com/-1.40.0--Beta-1-release-candidate-available-tp24902288... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vladimir Prus wrote:
Francesco Guerrieri wrote:
Hi, this is my first post to the ml, so I picked up a relatively easy task :-) I have built the boost-windows-2009-08-11 rc without any glaring errors, with visual studio 2010 beta1.
I simply did, from a visual studio 2010 prompt,
bootstrap bjam.exe --toolset=msvc-10.0 --build-type=complete >build_complete.log 2>&1
The resulting project -config.jam was very simple, just one line with
using msvc ;
The last line of the log are the following: ...failed updating 6 targets... ...skipped 22 targets... ...updated 2199 targets...
Hmm. Can you run the same command again, and post the error messages? It seems like some libraries does not work with msvc 10.0.
I had gotten similar problem earlier trying to build all with ICU & expat with msvc9. However, it might be something to do on my end with external libraries dependence, so I will have to test it further before I can report. KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
KTC wrote:
I had gotten similar problem earlier trying to build all with ICU & expat with msvc9. However, it might be something to do on my end with external libraries dependence, so I will have to test it further before I can report.
It now appears it's different errors I was getting. Nevertheless, I am unable to build everything without errors using VC 2008. :( For this test, I was compiling with VC9 on XP x64 inside a VM targeting x64. I had earlier tried it on x86 XP with VC9 with similar errors. Both setup had build 1.39 successfully. Basically, all the problems I'm having seems to evolve around Boost.Graph, in particular its optional components GraphML reader, and MPI. (The follow are all on --build-type=complete) 1st combination: No MPI, no GraphML, no ICU, yes bzip2, yes zlib. Build successful. 2nd combination: No MPI, no ICU, yes GraphML (with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and "<define>XML_STATIC" addition in Jamfile). Build failed 2, skipped 2. See build_complete_no_mpi_icu.log. (Errors also occurred when 0, 1, or the other change to the Jamfile was made.) 3rd combination: No ICU, no GraphML, yes MPI. Build failed 8, skipped 29. See a cut down version of the log in build_complete_no_icu_graphml.log. Regex with ICU was built successfully on its own specifying link & runtime-link. KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein 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. warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. ...patience... ...patience... ...patience... ...found 9819 targets... ...updating 72 targets... ...... msvc.link.dll x64\boost\bin.v2\libs\regex\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_regex-vc90-mt-gd-1_40.dll Creating library x64\boost\bin.v2\libs\regex\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_regex-vc90-mt-gd-1_40.lib and object x64\boost\bin.v2\libs\regex\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_regex-vc90-mt-gd-1_40.exp msvc.manifest.dll x64\boost\bin.v2\libs\regex\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_regex-vc90-mt-gd-1_40.dll common.copy stage\lib\boost_regex-vc90-mt-gd-1_40.dll x64\boost\bin.v2\libs\regex\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_regex-vc90-mt-gd-1_40.dll 1 file(s) copied. msvc.link.dll x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.dll Creating library x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.lib and object x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.exp graphml.obj : error LNK2019: unresolved external symbol __imp_XML_ParserFree referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_GetCurrentLineNumber referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_GetCurrentColumnNumber referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_ErrorString referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_GetErrorCode referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_Parse referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_SetUserData referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_SetCharacterDataHandler referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_SetElementHandler referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) graphml.obj : error LNK2019: unresolved external symbol __imp_XML_ParserCreateNS referenced in function "public: void __cdecl graphml_reader::run(class std::basic_istream<char,struct std::char_traits<char> > &)" (?run@graphml_reader@@QEAAXAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@@Z) x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.dll : fatal error LNK1120: 10 unresolved externals call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul link call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul link call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul link call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul link /NOLOGO /NOLOGO /NOLOGO /NOLOGO /INCREMENTAL:NO /INCREMENTAL:NO /INCREMENTAL:NO /INCREMENTAL:NO /DLL /DEBUG /DEBUG /DEBUG /DEBUG /MACHINE:X64 /MACHINE:X64 /MACHINE:X64 /MACHINE:X64 /subsystem:console /subsystem:console /subsystem:console /subsystem:console /out:"x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.dll" /IMPLIB:"x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.lib" /LIBPATH:"C:\expat-2.0.1\x64\bin\Release" /LIBPATH:"C:\expat-2.0.1\x64\bin\Release" /LIBPATH:"C:\expat-2.0.1\x64\bin\Release" /LIBPATH:"C:\expat-2.0.1\x64\bin\Release" @"x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.dll x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.lib x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph.pdb x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph.pdb x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph.pdb x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph.pdb... ...removing x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.lib ...skipped <pstage\lib>boost_graph-vc90-mt-gd-1_40.dll for lack of <px64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi>boost_graph.pdb... common.copy stage\lib\boost_graph-vc90-mt-gd-1_40.lib The system cannot find the file specified. copy /b "x64\boost\bin.v2\libs\graph\build\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_graph-vc90-mt-gd-1_40.lib" + this-file-does-not-exist-A698EE7806899E69 "stage\lib\boost_graph-vc90-mt-gd-1_40.lib" ...failed common.copy stage\lib\boost_graph-vc90-mt-gd-1_40.lib... ...removing stage\lib\boost_graph-vc90-mt-gd-1_40.lib common.copy stage\lib\boost_zlib-vc90-mt-gd-1_40.dll x64\boost\bin.v2\libs\iostreams\build\zlib\msvc-9.0\debug\address-model-64\architecture-x86\threading-multi\boost_zlib-vc90-mt-gd-1_40.dll 1 file(s) copied. ...... ...failed updating 2 targets... ...skipped 2 targets... ...updated 68 targets... 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. warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. ...patience... ...patience... ...patience... ...found 11830 targets... ...updating 131 targets... ...... call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul cl /Zm800 -nologo @"x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi\mpi_process_group.obj.rsp" ...failed compile-c-c++ x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi\mpi_process_group.obj... ..skipped <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>boost_graph_parallel-vc90-mt-1_40.dll for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>mpi_process_group.obj... ...skipped <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>boost_graph_parallel-vc90-mt-1_40.lib for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>mpi_process_group.obj... ...skipped <pstage\lib>boost_graph_parallel-vc90-mt-1_40.dll for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>boost_graph_parallel-vc90-mt-1_40.dll... ...skipped <pstage\lib>boost_graph_parallel-vc90-mt-1_40.lib for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\threading-multi>boost_graph_parallel-vc90-mt-1_40.lib... ...skipped <pstage\lib>boost_graph_parallel-vc90-mt.lib for lack of <pstage\lib>boost_graph_parallel-vc90-mt-1_40.lib... compile-c-c++ x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi\mpi_process_group.obj mpi_process_group.cpp C:\boost_1_40_0_beta1\boost/mpi/detail/mpi_datatype_primitive.hpp(57) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/mpi_datatype_primitive.hpp(75) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_oprimitive.hpp(53) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_oprimitive.hpp(84) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_oprimitive.hpp(95) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_oprimitive.hpp(99) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/binary_buffer_oprimitive.hpp(53) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/binary_buffer_oprimitive.hpp(86) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_iprimitive.hpp(63) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/packed_iprimitive.hpp(106) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/mpi/detail/binary_buffer_iprimitive.hpp(63) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data C:\boost_1_40_0_beta1\boost/graph/distributed/unsafe_serialize.hpp(40) : error C2182: 'unsafe_serialize' : illegal use of type 'void' C:\boost_1_40_0_beta1\boost/graph/distributed/unsafe_serialize.hpp(40) : error C2182: 'abstract declarator' : illegal use of type 'void' C:\boost_1_40_0_beta1\boost/graph/distributed/unsafe_serialize.hpp(46) : error C2770: invalid explicit template argument(s) for 'MPI_Datatype boost::mpi::get_mpi_datatype(const T &)' C:\boost_1_40_0_beta1\boost/mpi/datatype_fwd.hpp(28) : see declaration of 'boost::mpi::get_mpi_datatype' libs\graph_parallel\src\mpi_process_group.cpp(360) : warning C4244: 'initializing' : conversion from '__int64' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(467) : warning C4267: 'argument' : conversion from 'size_t' to 'const int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(561) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(921) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(929) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(1101) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64 >nul cl /Zm800 -nologo @"x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi\mpi_process_group.obj.rsp" ...failed compile-c-c++ x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi\mpi_process_group.obj... ...skipped <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi>libboost_graph_parallel-vc90-mt-gd-1_40.lib for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi>mpi_process_group.obj... ...skipped <pstage\lib>libboost_graph_parallel-vc90-mt-gd-1_40.lib for lack of <px64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi>libboost_graph_parallel-vc90-mt-gd-1_40.lib... ...skipped <pstage\lib>libboost_graph_parallel-vc90-mt-gd.lib for lack of <pstage\lib>libboost_graph_parallel-vc90-mt-gd-1_40.lib... compile-c-c++ x64\boost\bin.v2\libs\graph_parallel\build\msvc-9.0\release\address-model-64\architecture-x86\link-static\threading-multi\mpi_process_group.obj mpi_process_group.cpp .\boost/mpi/detail/mpi_datatype_primitive.hpp(57) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/mpi_datatype_primitive.hpp(75) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data \boost/mpi/detail/packed_oprimitive.hpp(53) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/packed_oprimitive.hpp(84) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/packed_oprimitive.hpp(95) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/packed_oprimitive.hpp(99) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/binary_buffer_oprimitive.hpp(53) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/binary_buffer_oprimitive.hpp(86) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/packed_iprimitive.hpp(63) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/packed_iprimitive.hpp(106) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/mpi/detail/binary_buffer_iprimitive.hpp(63) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data .\boost/graph/distributed/unsafe_serialize.hpp(40) : error C2182: 'unsafe_serialize' : illegal use of type 'void' .\boost/graph/distributed/unsafe_serialize.hpp(40) : error C2182: 'abstract declarator' : illegal use of type 'void' .\boost/graph/distributed/unsafe_serialize.hpp(46) : error C2770: invalid explicit template argument(s) for 'MPI_Datatype boost::mpi::get_mpi_datatype(const T &)' .\boost/mpi/datatype_fwd.hpp(28) : see declaration of 'boost::mpi::get_mpi_datatype' libs\graph_parallel\src\mpi_process_group.cpp(360) : warning C4244: 'initializing' : conversion from '__int64' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(467) : warning C4267: 'argument' : conversion from 'size_t' to 'const int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(561) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(921) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(929) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data libs\graph_parallel\src\mpi_process_group.cpp(1101) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data ...... ...failed updating 8 targets... ...skipped 29 targets... ...updated 94 targets...
On Wed, Aug 12, 2009 at 5:23 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Francesco Guerrieri wrote:
The last line of the log are the following: ...failed updating 6 targets... ...skipped 22 targets... ...updated 2199 targets...
Hmm. Can you run the same command again, and post the error messages? It seems like some libraries does not work with msvc 10.0.
Sure, I have attached in a txt the 6 failed targets. If needed I have the complete log, of course. They refer to the program_options and signals libraries.
Hmm, why do you actually need that? What docs are you reading? I think the procedure involving run.py does not use those tools at all.
Thanks, Volodya
Last time that I installed under Windows I started from the boostpro package so it was the first time that I followed those instructions. I found them in boost-windows-2009-08-11\tools\regression\doc\library_status.html, linked from boost-windows-2009-08-11\tools\regression\doc\index.html (under Library Status). Sorry for the confusion that I unwillingly arose by using those: as I said, they were slighly out of sync with my actual paths. I will go with run.py and will let you know. Francesco
Looking at the Signals code, i see that \libs\signals\src\named_slot_map.cpp (line 27) and boost\signals\named_slot_map.hpp (line 130) contain a #if BOOST_WORKAROUND(_MSC_VER, <= 1500) and changing both to <= 1600 allows it to build in vc10. The error only seems to occur when you build signals as a DLL, and the regression tests only seem to test with static linking, so there are no visible failures. -- View this message in context: http://www.nabble.com/-1.40.0--Beta-1-release-candidate-available-tp24902288... Sent from the Boost - Dev mailing list archive at Nabble.com.
Richard Webb wrote:
Looking at the Signals code, i see that
\libs\signals\src\named_slot_map.cpp (line 27)
and
boost\signals\named_slot_map.hpp (line 130)
contain a
#if BOOST_WORKAROUND(_MSC_VER, <= 1500)
and changing both to <= 1600 allows it to build in vc10.
I've opened a ticket for this -> <https://svn.boost.org/trac/boost/ticket/3344> -- View this message in context: http://www.nabble.com/-1.40.0--Beta-1-release-candidate-available-tp24902288... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, Aug 12, 2009 at 5:23 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Francesco Guerrieri wrote:
1) in the Generating library status page (boost-windows-2009-08-11\tools\regression\doc\library_status.html), the path to library_test.bat is ..\..\..\tools\regression\src\library_test and not ..\..\..\tools\regression\library_test. 2) another small glitch is that the Jamroot.jam didn't build the library_status.exe. I added a #~ just before "explicit library_status;" and it built, but contrarily to status.html indications both process_jam_log.exe and library_status.exe were to be found in a subdir of the bin\ folder (in my case they were to be found under boost-windows-2009-08-11\tools\regression\build\bin\msvc-10.0\release\threading-multi )
Hmm, why do you actually need that? What docs are you reading? I think the procedure involving run.py does not use those tools at all.
Hi, it appears to me that run.py does use those tools (process_jam_log.exe and library_status.exe). I had to copy them to a location where they could be found (.\ worked fine). I continued to have some problem. To double check if there's something not working with my machine (beta of vs2010, beta of windows 7), today I did a run.py from scratch. It worked fine, downloading from svn the sources (trunk branch), compiling, running the tests (by the way, I got quite a few assertion and core dumps with the tests, but they should appear in the uploaded logs) and uploading them to the ftp server. Maybe it's a solved problem by now, I have not yet read all the emails :-) I just wanted to follow up. Francesco
Having been shamed by the chatter about the lack of beta feedback, and coincidentally finding myself in need of some more recent boost features, I dropped the 1.40.0 beta1 ZIP over my 1.35.0 source tree and tried to build my system. So, what's the story on this _pRawDllMain thing? I see nothing but confusion and speculation in a quick search of the archives. This is a breaking change with no obvious resolution and it wasn't in the short list of known problems given in the beta announcement email. I think it should be in the release notes. I gather from the list chatter I did find that it's not a brand-new problem. I'll continue to dig for a solution. -swn libboost_thread-vc90-mt-1_40.lib(tss_pe.obj) : error LNK2005: _pRawDllMain already defined in dllmain.obj
On Wed, Aug 12, 2009 at 3:52 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Beman Dawes wrote:
1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems.
FWIW, I have tried on Linux, with both stage and install, and with both --layout=system, and --layout=versioned, and things worked OK.
Good! Thanks!
--build-type=complete does not work with ICU installed in the same way as reported by Václav Haisman.
It would be important to have somebody to test on Windows, using the "bootstrap.bat + .\bjam" procedure.
I've just tried that, and it worked fine AFAICS. One slight nit. build.bat used vc10, but I really wanted to test with vc9 (express). So I had to manually edit booststrap.bat to pass vc9 to build.bat. Thus it would have been slightly easier if the call to build.bat had been: call .\build.bat %1 > ..\..\..\bjam.log Thanks, --Beman
I get a serious error with Boost.Filesystem in the 1.40 beta: boost/filesystem/operations.hpp:510: error: expected identifier before 'int' It seems that BOOST_SCOPED_ENUM_START is not defined. This is using gcc on darwin. Matthias
Matthias Troyer wrote:
I get a serious error with Boost.Filesystem in the 1.40 beta:
boost/filesystem/operations.hpp:510: error: expected identifier before 'int'
It seems that BOOST_SCOPED_ENUM_START is not defined.
This is using gcc on darwin.
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
same with me VC8.0 + stlport
Matthias Troyer wrote:
I get a serious error with Boost.Filesystem in the 1.40 beta:
boost/filesystem/operations.hpp:510: error: expected identifier before 'int'
It seems that BOOST_SCOPED_ENUM_START is not defined.
This is using gcc on darwin.
Matthias
I opened ticket #3346 for this regression, and proposed a patch.
On Fri, Aug 14, 2009 at 12:18 PM, Matthias Troyer<troyer@phys.ethz.ch> wrote:
Matthias Troyer wrote:
I get a serious error with Boost.Filesystem in the 1.40 beta:
boost/filesystem/operations.hpp:510: error: expected identifier before 'int'
It seems that BOOST_SCOPED_ENUM_START is not defined.
This is using gcc on darwin.
Matthias
I opened ticket #3346 for this regression, and proposed a patch.
Applied to trunk. I'll merge to branches/release as soon as tests have cycled. Thanks for spotting this! --Beman
On Aug 15, 2009, at 8:24 AM, Beman Dawes wrote:
On Fri, Aug 14, 2009 at 12:18 PM, Matthias Troyer<troyer@phys.ethz.ch> wrote:
Matthias Troyer wrote:
I get a serious error with Boost.Filesystem in the 1.40 beta:
boost/filesystem/operations.hpp:510: error: expected identifier before 'int'
It seems that BOOST_SCOPED_ENUM_START is not defined.
This is using gcc on darwin.
Matthias
I opened ticket #3346 for this regression, and proposed a patch.
Applied to trunk. I'll merge to branches/release as soon as tests have cycled.
Thanks for spotting this!
I should set up a regular regression testing of our application codes with the release branch. I'll ask one of my people to do that. Matthias
Hi Beman, On Wednesday 12 August 2009, Beman Dawes wrote:
One slight nit. build.bat used vc10, but I really wanted to test with vc9 (express).
That is autodetection at work. It always uses the highest toolset available...
So I had to manually edit booststrap.bat to pass vc9 to build.bat. Thus it would have been slightly easier if the call to build.bat had been:
call .\build.bat %1 > ..\..\..\bjam.log
Please find a simple patch attached. Ok to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
libicuio.so.40.1 -rwxr-xr-x 1 root root 48536 2009-06-11 06:48 /usr/lib64/libicuio.so.40.1 lrwxrwxrwx 1 root root 16 2009-08-18 11:34 /usr/lib64/libicule.so ->
libicule.so.40.1 -rwxr-xr-x 1 root root 220936 2009-06-11 06:48 /usr/lib64/libicule.so.40.1 lrwxrwxrwx 1 root root 16 2009-08-18 11:34 /usr/lib64/libiculx.so ->
libiculx.so.40.1 -rwxr-xr-x 1 root root 54544 2009-06-11 06:48 /usr/lib64/libiculx.so.40.1 lrwxrwxrwx 1 root root 16 2009-08-18 11:34 /usr/lib64/libicutu.so ->
libicutu.so.40.1 -rwxr-xr-x 1 root root 115288 2009-06-11 06:48 /usr/lib64/libicutu.so.40.1 lrwxrwxrwx 1 root root 16 2009-08-18 11:34 /usr/lib64/libicuuc.so ->
On linux fedora f11 x86_64, I get: 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. Here's what I did: bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage All libicu stuff is in /usr/lib64 - maybe bjam didn't look there? ls -l /usr/lib64/*icu* lrwxrwxrwx 1 root root 18 2009-08-18 11:34 /usr/lib64/libicudata.so -> libicudata.so.40.1 lrwxrwxrwx 1 root root 18 2009-06-25 07:39 /usr/lib64/libicudata.so.40 -> libicudata.so.40.1 -rwxr-xr-x 1 root root 13916904 2009-06-11 06:48 /usr/lib64/libicudata.so.40.1 lrwxrwxrwx 1 root root 18 2009-08-18 11:34 /usr/lib64/libicui18n.so -> libicui18n.so.40.1 lrwxrwxrwx 1 root root 18 2009-06-25 07:39 /usr/lib64/libicui18n.so.40 -> libicui18n.so.40.1 -rwxr-xr-x 1 root root 1631184 2009-06-11 06:48 /usr/lib64/libicui18n.so.40.1 lrwxrwxrwx 1 root root 16 2009-08-18 11:34 /usr/lib64/libicuio.so -> libicuio.so.40.1 lrwxrwxrwx 1 root root 16 2009-06-25 07:39 /usr/lib64/libicuio.so.40 - libicule.so.40.1 lrwxrwxrwx 1 root root 16 2009-06-25 07:39 /usr/lib64/libicule.so.40 - libiculx.so.40.1 lrwxrwxrwx 1 root root 16 2009-06-25 07:39 /usr/lib64/libiculx.so.40 - libicutu.so.40.1 lrwxrwxrwx 1 root root 16 2009-06-25 07:39 /usr/lib64/libicutu.so.40 - libicuuc.so.40.1 lrwxrwxrwx 1 root root 16 2009-06-25 07:39 /usr/lib64/libicuuc.so.40 -
libicuuc.so.40.1 -rwxr-xr-x 1 root root 1327760 2009-06-11 06:48 /usr/lib64/libicuuc.so.40.1
participants (12)
-
Beman Dawes -
Francesco Guerrieri -
John Maddock -
Juergen Hunold -
KTC -
Matthias Troyer -
Neal Becker -
Richard Webb -
Stephen Nuchia -
Vladimir Prus -
Václav Haisman -
Zoran Cvetkov