Hello,
this little test program
#include boost/preprocessor.hpp
int main() { return 0; }
is compiled fine by gcc 2.95.3 and gcc 3.0.4.
However gcc 3.1/3.2 (and 3.3) produce errors:
In file included from /home/boost/boost/preprocessor/array.hpp:18,
from
Beman Dawes wrote:
Bjorn Karlsson and I are wondering if Boost should require copyrights on
Jamfiles.
Jamfiles are part of the build system; they won't become part of
a an executable. So everything is fine when a vendor ships a
binary or a DLL.
However, when Boost is incorporated to some other
Hi,
I suggest to apply the attached patch to
libs/filesystem/build/Jamfile.v2
The patch adds boost/filesystem as project-id.
Regards,
m
Index: Jamfile.v2
===
RCS file: /cvsroot/boost/boost/libs/filesystem/build/Jamfile.v2,v
Hi,
the attached patch fixes two typos in the release procedures document.
Regards,
m
Index: release_procedures.htm
===
RCS file: /cvsroot/boost/boost/more/release_procedures.htm,v
retrieving revision 1.5
diff -u -r1.5
Hi,
the attached patch fixes a typo in
libs/test/doc/execution_monitor.htm.
Regards,
m
Index: execution_monitor.htm
===
RCS file: /cvsroot/boost/boost/libs/test/doc/execution_monitor.htm,v
retrieving revision 1.10
diff -u -r1.10
Douglas Paul Gregor wrote:
I would like a volunteer ...
I gave it a try:
- html: works like a charm.
- onehtml ditto
- pdf: lots of messages regarding missing hyphenation pattern for
language en. A pdf file is created, however.
Is there a chance to specify a different paper size (e.g. A4)?
Hi,
I've found a little problem in boost_no_std_wstreambuf.cxx
The code uses std::ptrdiff_t but doesn't #include cstddef
I hesitated to add that #include because I don't know wether
all relevant compilers already support that.
With the current code, the results for Comeau C++ on Linux
are wrong.
Hi,
I found a problem with the intel configuration for Linux.
For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
gets defined although the compiler has an intrinsic wchar_t.
Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
defined on Linux. __WCHAR_TYPE__ is defined to int. Never-
John Maddock wrote:
I found a problem with the intel configuration for Linux.
For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
gets defined although the compiler has an intrinsic wchar_t.
Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
defined on Linux. __WCHAR_TYPE__ is defined to
John Maddock wrote:
Looking at the boost regression test results, it seems that Intel on linux
defines _WCHAR_T (which is what the EDG front-end documentation specifies
for wchar_t support), so I used that as the test - should be in cvs now -
can you check that it does the right thing?
Jens Maurer wrote:
It appears that the current tools/build/como-tools.jam is
not usable on Unix. For example, the linker action
causes REM lines to be passed to the Unix shell, which
does not work.
It looks to me that como-win32-tools.jam contains the Win32
configuration now, so I'd like to
Markus Werle wrote:
There is something wrong with the config.
Obviously the code should use the
BOOST_MPL_AUX_VALUE_WKND(C)::value
but it seems the output of my configure run is not
included.
...
result of configure run (user.hpp):
...
//
// options added by configure:
//
#define
Hi,
the attached patch changes the order in which compilers are checked in
config/select_compiler.hpp. This is required to detect Comeau C++
with gcc backend correctly.
ok to apply?
Regards,
m
Index: select_compiler_config.hpp
===
Alisdair Meredith wrote:
Spirit has also just released its next version, should this also be
integrated into any boost 1.30.1?
Yes, Spirit 1.6.1 should be incorporated into a Boost 1.30.1
release (if we actually decide to release 1.30.1).
[I will ask same question on Spirit list, and direct
Aleksey Gurtovoy wrote:
Martin Wille writes:
I'll run the tests for Linux and upload them as Linux-rc-1.30.0.
They should be available in a few hours.
Can you arrange the html so that it shows regressions from the 1.30.0
release results?
Hmm, I'd have to find out how I would do
Joel de Guzman wrote:
l.. Added missing include files to miniboost
For the records: that one doesn't apply to Boost 1.30.1.
Regards,
m
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thomas Witt wrote:
Vladimir Prus wrote:
| Reid Sweatman wrote:
|
| So, to summarize, I've no problem with the current name that I've
| introduced.
:-). Seriously having two functions that differ only by number is a
no-go to me.
| Of other suggestions create_directory_and_parents looks best
| to
David Abrahams wrote:
It appears that the tagging step for Version_1_30_1 got messed up
somehow.
Please have a look at RC_1_30_2, which is our release candidate for
Version 1_30_2, and let me know if there are any problems.
I'm not able to run the Linux regression tests on that branch.
David Abrahams wrote:
Martin Wille writes:
The fix made to the gcc toolset regarding the use of the
GXX variable should be backported to 1_30_2.
Please be more specific, i.e. post a patchset.
If I had a patchset then I would have applied it :)
(I sent a bug report some time ago
David Abrahams wrote:
Martin Wille writes:
Hello,
a couple of libraries are regressing for gcc-2.95.3/Linux:
date_time
graph
iterator
multi_array
numeric/interval
numeric/ublas (only with stlport)
random
variant
Are those libraries supposed to support gcc-2.95?
iterator
Beman Dawes wrote:
Assuming I'm release manager for 1.31.0, I'm going to publish explicit
release criteria for key platform/compiler pairs. Basically, the release
criteria will be 100% accounting for all failures on those
platform/compiler pairs.
I assume that Linux/GCC will be one of those
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for gcc3.1
Martin Wille wrote:
David Abrahams wrote:
Martin Wille writes:
The fix made to the gcc toolset regarding the use of the
GXX variable should be backported to 1_30_2.
Please be more specific, i.e. post a patchset.
If I had a patchset then I would have applied it :)
(I sent a bug report some
Martin Wille wrote:
If there is enough time left then I'll run the tests for
the 1.30.0 release and gcc-3.1.1. The chart for the
RC_1_30_0 branch should look better then.
Done. There are no regressions for gcc-3.3.1/Linux.
Regards,
m
___
Unsubscribe
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for gcc3.1
David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
...
I would be interested in
hearing about the plans for a Boost 1.31 release
As far as I know the CVS is in very good health at the moment. The
only major thing I know needs to be done is to complete the
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
It appears that the tagging step for Version_1_30_1 got messed up
somehow.
Please have a look at RC_1_30_2, which is our release candidate for
Version 1_30_2, and let me know if there are any problems.
I'm not able to run
Fernando Cacciola wrote:
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
...
Well, 3.4 isn't even a released compiler so As far as I'm concerned
it doesn't count.
I added 3.4 only for informational purpose. There is no
point in actively support a compiler that is still
Hello,
a couple of libraries are regressing for gcc-2.95.3/Linux:
date_time
graph
iterator
multi_array
numeric/interval
numeric/ublas (only with stlport)
random
variant
Are those libraries supposed to support gcc-2.95?
Regards,
m
___
Aleksey Gurtovoy wrote:
Martin Wille wrote:
The new reports are now checked into the main trunk and RC_1_30_0
branch.
Martin, if you are interested in upgrading to these, you would need to
re-generate the expected results file from the 1.30.0 tarball run - it
has
to contain more information
Aleksey Gurtovoy wrote:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Misha and Aleksey -- I think we really need to distinguish those
failures from real regressions in the chart somehow or we'll never be
able to tell where we stand.
Here -
Thomas Witt wrote:
Martin Wille wrote:
| David Abrahams wrote:
|
|
| The config_test regression was caused by not having linked against
| librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch:
Just out of curiosity. What the heck is librt?
It contains the implementation
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for gcc3.1 and gcc3.2.3
config_test regresses for intel 7.1
Martin Wille wrote:
6 tests fail for 3.2.3 and 6 tests fail for 3.3.1
Doh. 5 tests fail for 3.3.1. Sorry for the typo.
Regards,
m
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams wrote:
Samuel Krempp [EMAIL PROTECTED] writes:
...
Unfortunately, I left home again and I'd have a hard time commiting
changes to the boost cvs where I am now.
can you please make the changes to
$Boost/libs/format/tests/Jamfile and commit ?
oh, and while you're at it,
the
David Abrahams wrote:
I have fixed the last regression (the one with crc_test) in CVS, so
as soon as you've made your patch and we've had one more round of
testing, I'm going to tag it for release. Please let me know the
instant you're finished.
Bad news, there is a new problem: One test uses
an
David Abrahams wrote:
I believe I have now eliminated all the regressions in the RC_1_30_0
branch, though recent test updates at
http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to
contradict that. I find that very strange because I specifically
reproduced those problems and addressed
Hi,
I found a problem in execution_monitor.cpp of Boost.Test
on POSIX systems.
The file uses the sigsetjmp() and siglongjmp() functions
and the sigjmp_buf data type.
They all are defined by POSIX as an extention to the
ANSI-C standard, i.e. the interface is defined in a
header file defined by
Aleksey Gurtovoy wrote:
Below are the remaining changes that need to be commented on:
martin_wille
* tools/build/intel-linux-tools.jam: need -lrt, always
intel-linux-tools: added rt to FINDLIBS in order to make the
clock_gettime() function available (backport of a patch in
CVS HEAD)
Regards,
Gennadiy Rozental wrote:
My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you
Trey Jackson wrote:
Just a question I thought of while looking at the Boost regression
test results.
It appears that stlport is only used with gcc 2.95.3 (and in Windows
with Intel's C++ compiler and MS C++ 6.0).
Is boost moving away from supporting stlport?
There is no such intention.
Hello,
I'd like to inform you about regressions in the current
state of CVS wrt Linux (see http://tinyurl.com/k36t).
Boost.CRC:
crc_test regresses for gcc-3.1 and gcc-3.2.3
Boost.Date_Time:
almost all tests regress for gcc-2.95.3
testperiod regresses for intel-7.1
Boost.Graph:
graph
Anthony Williams wrote:
The following HTML is being added to the bottom of every page from
www.boost.org:
iframe src=http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0
frameborder=0 marginwidth=0 marginheight=0/iframe
This looks very much like the problem Boost's provider had a few
Jeff Garland wrote:
The regression test page seems to be on a diet
http://boost.sourceforge.net/regression-logs/
You can find some of the other results at
http://boost.sourceforge.net/regression-logs/release
However, I'm not sure wether that is official already.
Regards,
m
44 matches
Mail list logo
