- Boost - lists.boost.org

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 08 Oct '04

08 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Thanks for your help! Indeed, Boost.MultiIndex generates horribly long symbol names, it's a pita when trying to decode compiler errors (comparatively, regular STL errors are even pleasant to deal with). I'll have to think some way to shorten them in future releases. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX
by Joaquín Mª López Muñoz 08 Oct '04

08 Oct '04

Seems like some multi_index tests are failing due to lack of resources or something like that, for COMSOFT reports. http://tinyurl.com/66t2h mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: [very long expression] Anyone has an idea what this could be about? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Problematic inclusion of "pthread.h".
by Markus Schöpflin 08 Oct '04

08 Oct '04

When compiling the smart pointer tests with gcc 3.4.2 on Tru64, two tests fail with an error message. (See http://tinyurl.com/4jngu ) As far as I can see, the shared pointer implementation at some point includes the "pthread.h" system header file but gcc on Tru64 requires that -pthread must be specified on the command line when including this header file. When running this test with gcc 3.4.2 on Linux the file "pthread.h" is also included but gcc doesn't require the addition of -pthread in the command line on this platform. This leads to the question whether it is ok to include "pthread.h" without specifying -pthread on the command line. Does anyone know an answer to this? Markus

5 26

Re: uBLAS broken on MSVC 6.5
by Michael Stevens 08 Oct '04

08 Oct '04

Alekskey, > Seems like some recent changes brought MSVC to its knees -- > http://tinyurl.com/3vmlv. Fix is already committed. Tomorrow we should be all green again. My plan is for this release is to get maximum compatibility with the older compilers. In particular VC6.5 7.0, GCC 2.95, Intel 7.0, and CV8.3 Then after this release I can drop many of the multitude of workaround necessary for these. With regard to Code Warrior I was hoping to develop a fix for the debug mode compilation errors show up on you metacomm test. I didn't come up with anything satisfactory however. Do you have any idea why there is such a large difference between your cw-8.3 and the RSI's cw-8.3-release tests? I can only see the command line options in the failing build. The only option I can see which could be of relevance is the '-iso-template on'. If you are both using stock versions of the build system this same option should be set for the release build as well. Thanks for you interest (and hard work), Michael

2 2

Re: Re: [boost] [serialization] test_level_class_info_load*...
by Robert Ramey 08 Oct '04

08 Oct '04

>First, you need to "fix" your Jamfile to return the test targets: >... OK >=================================================================== >Having that working, lets you define the tests so that they depend on >each other (indirectly). For example: >=================================================================== >local test-suite-serialization-part-1 = > [ test-bsl-run_files test_array ] > [ test-bsl-run_files test_binary ] >; >local test-suite-serialization-part-2 = > [ test-bsl-run_files test_contained_class ] > [ test-bsl-run_files test_cyclic_ptrs ] >; >test-suite serialization : > $(test-suite-serialization-part-1) > $(test-suite-serialization-part-2) >; >DEPENDS $(gLOCATE($(test-suite-serialization-part-2):G=directory-grist) > : $(test-suite-serialization-part-1) >; Now - out of curiosity, most of the rule are of the form: rule test-bsl-run_polymorphic_archive ( test-name : sources * ) which suggests to me that I could just use: test-suite serialization : [ test-bsl-run_files test_level_class_info_load test_level_class_info_save ] Which would make ...load dependant on ...save. Or this is this answered by the following: >That last DEPENDS makes the directory for the part 2 depend on the >completion of part 1. You may ask why the directory and not the test >itself? Strangely it's because to properly chain the tests you need to >make the earliest step of the second test depend on the latest part of >the next test. And directories are the only sure thing that you can know >a test needs first. Robert Ramey

2 1

using boostbook on Windows
by Wieger Wesselink 07 Oct '04

07 Oct '04

I tried to use boostbook with native Windows, and ran into a few problems. There were two things that took me several hours to figure out. May be this could be added to the installation notes? 1) Apparently the order of the 'using boostbook' and 'using doxygen' declarations in user-config.jam matters; I did it wrong at first, and the resulting errors were incomprehensible to me: warning: Doxygen initialization: Boost.Build stylesheets not found 2) I needed to empty the bin.v2 directory to make it work. This was something I hadn't thought about, and again the error messages were quite incomprehensible. Finally, the generation of PDF doesn't work because of a problem with the jam files. It seems that fop.sh is called instead of fop.bat. Perhaps someone could have a look at this? ...found 20 targets... ...updating 1 target... fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf 'JAVA_HOME' is not recognized as an internal or external command, operable program or batch file. JAVA_HOME=D:/java/jdk1.5.0 D:/cpp/boostbook/fop-0.20.5/fop.sh ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.fo ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf ...failed fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf... ...failed updating 1 target... If I run this from the command line with fop.bat, the file boostbook.pdf is successfully created. I have used the following settings: --- user-config.jam --- using xsltproc ; using boostbook : d:/cpp/boostbook/docbook-xsl-1.66.1 : d:/cpp/boostbook/docbook-xml-4.2 ; using doxygen ; using fop : D:/cpp/boostbook/fop-0.20.5 : D:/java/jdk1.5.0 ; Regards, Wieger -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

1 0

Fixing broken links
by Aleksey Gurtovoy 07 Oct '04

07 Oct '04

It would be appreciated if the maintainers of the following libraries took care of the corresponding issues listed in http://www.meta-comm.com/engineering/boost/links.html: algorithm build date_time iterator numeric/conversion optional program_options python range serialization test thread TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

6 5

Latest cvs causes segfault on gcc version 3.4.2 20041003 (Red Hat 3.4.2-4)
by Neal D. Becker 07 Oct '04

07 Oct '04

This is current gcc for Linux/FC3T2. (Fedora core 3 test 2) /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp: In constructor `boost::python::detail::tuple_base::tuple_base(const boost::python::api::object&)': /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp:21: internal compiler error: Segmentation fault Bug report filed.

4 6

Re: [boost] Re: [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjpj7l$9c2$2(a)sea.gmane.org> dheld(a)codelogicconsulting.com (David B. Held) wrote (abridged): > > I had a quick look from my mobile phone, and it worked > > reasonable well. > > Is this an important use case? I can't remember a single time where > I said to myself: "It would be really handy to look up some Boost > documentation from my phone right now." I'm a bit of a web purist. I think it should be viewable from anywhere unless there's a good reason not to be. Partly because there's so much variety in clients. Anyway, even if we do all have huge hi-res desk-top monitors available, screen real estate is precious. A good web-site should cope gracefully with small browser windows. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: The Smart Container library
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjbuc0$csa$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It has never been the intention to support a path of "upgrade". The > semantics are very different from vector<shared_ptr<T> > and > ptr_vector<T>. The semantics are closer to vector<T> when it comes > to "copying". OK, thanks. It sounds like the library isn't really doing what I expect or want. To the point where I question whether "ptr_vector" is a good name for it, since it does not behave like a vector of pointers. Maybe something like "poly_vector" would better reflect the intent. I think I've missed the end of the review period now - they just whizz past, don't they? - but that probably doesn't matter because all I can really say is that I don't think I am a prospective user of the library. I might have been interested in a container which took ownership of the things pointed-to, but was otherwise a simple container of pointers. -- Dave Harris, Nottingham, UK

1 0