- Boost - lists.boost.org

[Boost.build] Install_name wrong on OS X dylibs with latest CVS
by Mike Jackson 01 Feb '08

01 Feb '08

I just checked out and built boost on OS X 10.4 and there is a problem with the "install_name" or "rpath" on the dynamic libraries that are built. The "install_name" that is embedded in the libraries are basically useless as they do not contain a correct path to the libraries. Example for the filesystem is: 532:[mjackson@Thor:boost]$ otool -L /Users/Shared/Sandbox/boost- install/lib/libboost_filesystem-1_35.dylib /Users/Shared/Sandbox/boost-install/lib/libboost_filesystem-1_35.dylib: bin.v2/libs/filesystem/build/darwin/release/ libboost_filesystem-1_35.dylib (compatibility version 0.0.0, current version 0.0.0) bin.v2/libs/system/build/darwin/release/ libboost_system-1_35.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) There are a couple of choices for the "Correct" value. The best (IMHO) would be to put in the absolute path to the installed library, so on my system that would be: /Users/Shared/Sandbox/boost-install/lib/libboost_filesystem-1_35.dylib We could also put _no_ path on the install_name, but that requires the user to additionally set the DYLD_LIBRARY_PARH which Apple discourages. The fix would be to add the following to the "actions link.dll bind LIBRARIES" section of the boost/tools/build/v2/tools/darwin.jam file: -headerpad_max_install_names -install_name "{Install_prefix_lib_location}$(<[1]:D=:S=.dylib)" ..... I do not know anything about bjam so I have no idea how to get the "Install_prefix_lib_location". Could some one tell me how to get at that value somehow and I will create a patch. -- Mike Jackson OS X Build Specialist

3 4

Gauging interest for MT async signals utility
by Roland Schwarz 01 Feb '08

01 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Behaviour of standard signal.h / csignal is known to be different on windows and posix platforms. While on posix typically there is no provision for the thread context the signal handler will run, on windows the operating system delivers signals into a separate dedicated thread. This makes it possible e.g. to use locking primitives without risk for deadlock. I wrote a little utility that mimics that behavior on posix platforms by blocking all signals during application startup and launching a dedicated thread that has signal handling turned on. Since every other thread (that has been started after main) inherits the all-blocking sigmask, there is only one thread to handle the signals. The utility also allows a boost function pointer for the signal handler. I would be interested if there is believe such a utility would be worth including to boost. Also I would be interested on critics and opinions. A little usage example that would deadlock on posix when using std signal() instead of reset_signal(): boost::mutex mx; void foo(int sig) { std::cout << "foo attempting to lock" << std::endl; boost::mutex::scoped_lock lk(mx); std::cout << "foo got lock" << std::endl; } int main(int argc, char* argv[]) { reset_signal(SIGINT, foo); boost::mutex::scoped_lock lk(mx); std::cout << "main got lock, holding it now for 10 secs" << std::endl << "pressing ctrl-c triggers the handler" << std::endl ; sleep(10); lk.unlock(); std::cout << "unlocked, waiting another 10 secs" << std::endl; sleep(10); std::cout << "main ending" << std::endl; return 0; } - -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo1ENXW/dzA70DqARAqIUAJ4mhBCCYzWfDwJPfE6hQugtcm7bDgCePCQl 9J/vCHcpM6uplXk8VSpMVDg= =ldmb -----END PGP SIGNATURE-----

1 0

[1.35.0] Host for release snapshots?
by Beman Dawes 01 Feb '08

01 Feb '08

If we are going to generate release snapshots nightly, we need a site to host them. Is Sourceforge a possibility? I seem to recall the Sourceforge release mechanism isn't particularly friendly to nightly snapshots. Ideas? --Beman

2 2

[1.35.0] Building the release?
by Beman Dawes 01 Feb '08

01 Feb '08

I'm starting to test build release candidate files for 1.35.0. The 1.34.0 and 1.34.1 release candidates were build by hand, IIUC. There is a Python script to do that job (boost-root/tools/release/make_tarballs.py), but it is out of date. I'm starting to work on updating it. What does such a script have to do? * Export SVN branches/release with the correct line endings for POSIX and Windows. * Build the quickbook/boostbook docs. * Set various file permissions. * Build the actual .zip, .gz, .bz2, and .7z files. What else? Where do the beta.boost.org web pages come from? --Beman PS: In the future, I think we should start building release files nightly for the next release as soon as a release ships. That will speed the process of identifying problems.

6 12

[review] Review of Flyweight library begins today January 7
by Ion Gaztañaga 01 Feb '08

01 Feb '08

The formal review of Flyweight library, proposed by Joaquín M. López Muñoz, begins today (sorry for the late announcement): *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

9 18

constrained_value + fixed-pt
by Neal Becker 01 Feb '08

01 Feb '08

I've been looking at constrained_value. It looks great to me, I'd love to see this added to boost. I wonder if any thought has been given (or work done) in using this to implement fixed point arithmetic?

1 0

[rfc] I/O Chain Library, Preview Release
by Sebastian Redl 01 Feb '08

01 Feb '08

Hi, Back in June I posted some thoughts about what I'd expect from a properly done I/O library.[1] Based on the ensuing discussion I then designed such a library. Over the last months, I've worked hard at implementing the thing. It is with quite a bit of pride, then, that I announce the IOChain preview release 1. You can get the source here: http://stud3.tuwien.ac.at/~e0226430/iochain-preview-1.tar.bz2 There are currently some assumptions in the build files that require a tiny bit of setup. 1) Unpack the source into some directory. 2) Grab the latest Boost trunk. 3) In the unpacked source, make a symlink to the Boost trunk called "realboost". E.g. tar -xjf iochain-preview-1.tar.bz2 cd iochain ln -s /path/to/boost/trunk realboost 4) Add zlib to your user config. If you have zlib where it is easily found, this is as easy as adding this line to ${HOME}/user-config.jam: lib zlib : : <name>z ; I'm sorry for the inconvenience. Documentation is in quickbook format. A generated version is available here: http://stud3.tuwien.ac.at/~e0226430/iochain/ This is a preview release. Its only purpose is to get comments. It has not seen widespread compiler testing yet (only GCC 4.1 on a 64-bit Linux). Features implemented so far: - The infrastructure. - File I/O (POSIX only - a Win32 implementation exists, but hasn't seen a compiler yet, so don't expect it to compile, much less work) - In-memory I/O (fixed buffers and std::vector). - Read-ahead and write-collect buffers (like buffering in the current streams). - Various tools to support backtracking. - Combining bytes into larger types. (Only naive methods currently.) - On-the-fly CRC calculation. - On-the-fly zlib compression. The ultimate goal of the library is to completely replace iostreams. All discussion, suggestions, and criticisms are welcome. Sebastian Redl [1] http://lists.boost.org/Archives/boost/2007/06/123478.php

5 11

[Pool] CRITICAL _SECTION ambiguous symbol
by Samuel Debionne 01 Feb '08

01 Feb '08

Hello all, I have the following compile error in my project, using the SVN release branch : boost\boost\boost/pool/detail/mutex.hpp(67) : error C2872: 'CRITICAL _SECTION' : ambiguous symbol could be 'C:\Program Files\Microsoft Platform SDK\include\winbase.h(295) : RTL_CRITICAL_SECTION CRITICAL_SECTION' or 'third_party\boost\boost\boost/detail/lwm_win32_cs.hpp(33) : boost::d etail::CRITICAL_SECTION' It can be easly by fixed by adding "::" in front of the CRITICAL_SECTION member definition of the win32_mutex class (see pool/detail/mutex.hpp). But is there any reason not to use boost/detail/lightweight_mutex.hpp in the pool library ? Regards, Samuel

1 0

[property_tree] - segmentation fault
by Kowalke Oliver (QD IT PA AS) 01 Feb '08

01 Feb '08

Hello, I get an segmentation fault from the property_tree (1_35 trunck): Program terminated with signal 11, Segmentation fault. #0 0xb7cba2ba in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0xb7cba2ba in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 #1 0x080d4107 in pair (this=0xa44f1284, __a=@0x891acbc, __b=@0x891acc0) at /usr/include/c++/4.2/bits/stl_pair.h:85 #2 0x080d0510 in boost::property_tree::basic_ptree<std::less<std::string>, std::string, boost::property_tree::basic_path<std::string>, std::string, boost::property_tree::translator>::insert<std::_List_const_iterator<std::pair<std::string, boost::property_tree::basic_ptree<std::less<std::string>, std::string, boost::property_tree::basic_path<std::string>, std::string, boost::property_tree::translator> > > > ( this=0xa44f1318, where={_M_node = 0xa44f131c}, first={_M_node = 0x891acb4}, last={_M_node = 0x891bf80}) at /opt/boost/include/boost-1_35/boost/property_tree/detail/ptree_implementation.hpp:304 #3 0x080d0648 in basic_ptree (this=0xa44f1318, rhs=@0x891bf7c) at /opt/boost/include/boost-1_35/boost/property_tree/detail/ptree_implementation.hpp:65 Any ideas what happened - until now property_tree worked without probs!? best regards, Oliver

1 0

<kein Betreff>
by Hansi Hansi 01 Feb '08

01 Feb '08

>> >> I took Matthias' suggestion above to mean he thought the density >> accumulator could be given additional "min" and "max" constructor >> parameters, not that we need a whole new accumulator. Matthias, was >> that >> what you were suggesting? I'd rather go that route. >Yes, that was my suggestion. Or we could implement the current one >based on the simpler one. >Matthias Okay. Maybe I have missunderstood something. Should the implementation be in the class density and optional min/max parameters? Best regards Hansjörg _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

1 0