On Wednesday 01 February 2006 09:10, Lars Gullik Bjønnes wrote: > Rex Dieter <[EMAIL PROTECTED]> writes: > | Jose' Matos wrote: > | > FWIW this is already fixed in latest CVS and soon to be 1.4.0pre4... > | > | Another failure, now with pre4 (this one seems not so trivial): > > To me this looks like a problem with gcc or boost (I see the same > problem) and this issue should be to either or both of them. > (As the code compiles and runs with gcc 4.0.x, and fails with gcc 4.1 > prerelease, that seems plausible to me...)
The boost used is the one we carry. Since this is an older version I don't know what it will be their reaction... Also as you know gcc has become more strict regarding the code it allows. > | /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > | -I. -I../../src -I./.. -I../../boost -O2 -g -pipe -Wall > | -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > | --param=ssp-buffer-size=4 -m64 -mtune=nocona -c -o render_graphic.lo > | render_graphic.C > | g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -O2 -g > | -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > | --param=ssp-buffer-size=4 -m64 -mtune=nocona -c render_graphic.C -o > | render_graphic.o > > btw. where are all these funky args to g++ comming from? > (and seemingly they turn -fno-exceptions off... which is one switch > that we "require") From $RPM_OPT_FLAGS or something like it, this carries the right flags for the used arch. > If possible a small testcase should be made, perhaps based on > render_graphic.C, that shows this error. -- José Abílio
