On Tue, Feb 3, 2009 at 9:34 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
1) When I try "bjam release" on my system with toolset=darwin (the correct
toolset), I get all kinds of errors from the -gdwarf-2 option.
It looks like this option is being added unconditionally on darwin.jam line 332. What exactly is the error?
hundreds of lines of this: /var/tmp//cco8nWgI.s:11638:Complex expression. Absolute segment assumed. /var/tmp//cco8nWgI.s:11640:Complex expression. Absolute segment assumed. /var/tmp//cco8nWgI.s:11644:Complex expression. Absolute segment assumed.
What is the command line being used?
"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -dynamic -no-cpp-precomp -gdwarf-2 -Wno-long-double -fPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"../.." -I"../../.." -c -o "../../../bin.v2/libs/algorithm/sorting/darwin-4.0.1/release/sample.o" "samples/sample.cpp"
Can you figure out what the command line should be?
I deleted -gdwarf-2 from darwin.bjam, and tune.pl is working fine with bjam now.
2) How do I find (or move) the executables bjam builds? It's building
them in ../../../bin.v2/libs/algorithm/sorting/darwin-4.0.1/debug/, which won't work on other systems if I provide a link in tune.pl.
I included a --tune option that uses the release variant and forces everything to be built in the directory of the Jamfile.
tune.pl is now using that Jamfile, and I've uploaded a revised algorithm_sorting.zip to the Boost Vault. Thanks for the help making tune.pl work with Jam, and now it's ready for people to try. I'm expecting Windows results to be worse than LINUX/UNIX/CYGWIN, and would like to improve them. Looking at my performance vs. range graph, combined with knowledge of some odd results on tune.pl inspired me to make an optimization to spreadsort that makes it a significantly faster for 11-bit and 21-bit ranges (MAX_SPLITS + 1 and MAX_SPLITS*2 + 1). Those two graph points are now out of date; I'll update them eventually.