Compilation problem with date_time and iostream gzip (and bzip2) filters
This simple test fails to compile with gcc 4.0.1 (or 4.0.2, it's the
debian unstable version) and boost 1.33.0 if the date_time include is
uncommented.
Is there any known incompatibility between the two libraries ?
#include
tonton wrote:
This simple test fails to compile with gcc 4.0.1 (or 4.0.2, it's the debian unstable version) and boost 1.33.0 if the date_time include is uncommented.
Is there any known incompatibility between the two libraries ?
This appears to be the GCC 4.0 + SFINAE + anonymous enum problem discussed in this thread: http://lists.boost.org/Archives/boost/2005/08/91958.php. I'd guess that Date_Time is using anonymous enum (directly or indirectly) and it's interfering with a SFINAE'd operator in Iostreams, or vice versa. Even if I can fix the interaction between Date_Time and Iostreams, it may still be a problem when one of the two libraries is used with certain non-Boost libraries. I'll work on fixing it. In the mean time, it would be helpful if you could name the several anonymous enums defined in Iostreams and report back. E.g., at line 148 of boost/iostreams/filter/aggregate.hpp, change enum { to enum flag_type { (you can use the name "flag_type" everywhere.) The affected files seem to be boost/iostreams/filter/aggregate.hpp boost/iostreams/filter/gzip.hpp boost/iostreams/filter/line.hpp boost/iostreams/filter/symmetric.hpp Jonathan
Jonathan Turkanis wrote:
This appears to be the GCC 4.0 + SFINAE + anonymous enum problem discussed in this thread: http://lists.boost.org/Archives/boost/2005/08/91958.php. I'd guess that Date_Time is using anonymous enum (directly or indirectly) and it's interfering with a SFINAE'd operator in Iostreams, or vice versa. Even if I can fix the interaction between Date_Time and Iostreams, it may still be a problem when one of the two libraries is used with certain non-Boost libraries.
OK. I've seen that this was a problem with anonymous enums, but I haven't found the exact reason.
I'll work on fixing it. In the mean time, it would be helpful if you could name the several anonymous enums defined in Iostreams and report back. E.g., at line 148 of boost/iostreams/filter/aggregate.hpp, change
There is more files with anonymous enums in iostream. a quick grep gives this: $ rgrep "enum {" boost/iostreams/* boost/iostreams/code_converter.hpp: enum { boost/iostreams/detail/streambuf/indirect_streambuf.hpp: enum { boost/iostreams/filter/line.hpp: enum { boost/iostreams/filter/symmetric.hpp: enum { boost/iostreams/filter/gzip.hpp: enum { boost/iostreams/filter/gzip.hpp: enum { boost/iostreams/filter/aggregate.hpp: enum { I changed them, and the example in my first post compiles, with both gzip and bzip2 filters. Patch attached. Thanks for the quick response
Jonathan
tonton wrote:
Jonathan Turkanis wrote:
This appears to be the GCC 4.0 + SFINAE + anonymous enum problem discussed in this thread: http://lists.boost.org/Archives/boost/2005/08/91958.php. I'd guess that Date_Time is using anonymous enum (directly or indirectly) and it's interfering with a SFINAE'd operator in Iostreams, or vice versa. Even if I can fix the interaction between Date_Time and Iostreams, it may still be a problem when one of the two libraries is used with certain non-Boost libraries.
OK. I've seen that this was a problem with anonymous enums, but I haven't found the exact reason.
I'll work on fixing it. In the mean time, it would be helpful if you could name the several anonymous enums defined in Iostreams and report back. E.g., at line 148 of boost/iostreams/filter/aggregate.hpp, change
There is more files with anonymous enums in iostream. a quick grep gives this: $ rgrep "enum {" boost/iostreams/* boost/iostreams/code_converter.hpp: enum { boost/iostreams/detail/streambuf/indirect_streambuf.hpp: enum { boost/iostreams/filter/line.hpp: enum { boost/iostreams/filter/symmetric.hpp: enum { boost/iostreams/filter/gzip.hpp: enum { boost/iostreams/filter/gzip.hpp: enum { boost/iostreams/filter/aggregate.hpp: enum {
I changed them, and the example in my first post compiles, with both gzip and bzip2 filters. Patch attached.
Great! Thanks for the patch. The fix will appear in 1.33.1
Thanks for the quick response
Jonathan
Been looking at this one for a bit, and thought I would post to see if anyone else has has this problem. BASIC INFO: I am running OS X 10.4.2 I have Bjam successfully configured to build boost and run the regression tests (YEAH!) In user-config.jam, I have set my tools=darwin as opposed to gcc (gcc does NOT work on Mac OS with boost due to the "zerolink" functionality apple added to GCC) I have been searching google and so far have found other people with a simliar problem, most notably when porting BSD apps to OSX. (but as of yet no solution) As it sits right now, I am trying to get the documentation to build with BJAM, but running the jamfile in \boost_root\docs is failing on a build of Quickbook. Below is the details of the attempted BJAM of quickbook directly. Any thoughts or help appreciated. Thanks, Brian DETAILS: $ bjam --v2 warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). ...patience... ...found 772 targets... ...updating 2 targets... darwin.link ../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/qu ickbook /usr/bin/ld: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status g++ -o "../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/q uickbook" "../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/q uickbook.o" "../../bin.v2/libs/program_options/build/darwin/debug/link-static/runtime-li nk-static/libboost_program_options-sd-1_33.a" -g -static ...failed darwin.link ../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/qu ickbook... darwin.link ../../dist/bin/quickbook /usr/bin/ld: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status g++ -s -o "../../dist/bin/quickbook" "../../bin.v2/tools/quickbook/darwin/release/link-static/runtime-link-static /quickbook.o" "../../bin.v2/libs/program_options/build/darwin/release/link-static/runtime- link-static/libboost_program_options-s-1_33.a" -static ...failed darwin.link ../../dist/bin/quickbook... ...failed updating 2 targets...
More info-
I took the link command (from below error) copy- pasted- and removed the
-static (per an usenet posting I saw with a similar fix)
DOING THIS, allowed quickbook to build a DEBUG but not a release.
There appears to be a bjam\config BUG with the quickbook jam file using the
darwin toolset.
I then used my user-config.jam to give it an explict path to the quickbook
binary. So far so good, for me at least. It looks like the docs are now
building.
BUT- this leaves open the problem of this not working on OSX. I am *not* an
expert on BJAM, but I am more than willing to try out things and debug this
for the benefit of fixing this bug.
If anyone (who is smarter about BJAM than me) who would like to help fix
this bug. You are welcome to send mail on this list or send mail to me
privately.
Thanks,
Brian
On 9/4/05 10:02 AM, "Brian Braatz"
Been looking at this one for a bit, and thought I would post to see if anyone else has has this problem.
BASIC INFO:
I am running OS X 10.4.2 I have Bjam successfully configured to build boost and run the regression tests (YEAH!) In user-config.jam, I have set my tools=darwin as opposed to gcc (gcc does NOT work on Mac OS with boost due to the "zerolink" functionality apple added to GCC)
I have been searching google and so far have found other people with a simliar problem, most notably when porting BSD apps to OSX. (but as of yet no solution)
As it sits right now, I am trying to get the documentation to build with BJAM, but running the jamfile in \boost_root\docs is failing on a build of Quickbook.
Below is the details of the attempted BJAM of quickbook directly.
Any thoughts or help appreciated.
Thanks,
Brian
DETAILS:
$ bjam --v2
warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). ...patience... ...found 772 targets... ...updating 2 targets... darwin.link ../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/quic kbook /usr/bin/ld: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status
g++ -o "../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/qui ckbook" "../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/qui ckbook.o" "../../bin.v2/libs/program_options/build/darwin/debug/link-static/runtime-link -static/libboost_program_options-sd-1_33.a" -g -static
...failed darwin.link ../../bin.v2/tools/quickbook/darwin/debug/link-static/runtime-link-static/quic kbook... darwin.link ../../dist/bin/quickbook /usr/bin/ld: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status
g++ -s -o "../../dist/bin/quickbook" "../../bin.v2/tools/quickbook/darwin/release/link-static/runtime-link-static/q uickbook.o" "../../bin.v2/libs/program_options/build/darwin/release/link-static/runtime-li nk-static/libboost_program_options-s-1_33.a" -static
...failed darwin.link ../../dist/bin/quickbook... ...failed updating 2 targets...
On Fri, 26 Aug 2005 16:57:52 -0600, Jonathan Turkanis wrote
tonton wrote:
This simple test fails to compile with gcc 4.0.1 (or 4.0.2, it's the debian unstable version) and boost 1.33.0 if the date_time include is uncommented.
Is there any known incompatibility between the two libraries ?
This appears to be the GCC 4.0 + SFINAE + anonymous enum problem discussed in this thread: http://lists.boost.org/Archives/boost/2005/08/91958.php.
This thread discusses vc7.1 -- not sure I see the connection unless you are saying gcc 4 has the same problem?
I'd guess that Date_Time is using anonymous enum (directly or indirectly)
It's indirect... Jeff
On 8/27/05, Jeff Garland
On Fri, 26 Aug 2005 16:57:52 -0600, Jonathan Turkanis wrote
tonton wrote:
This simple test fails to compile with gcc 4.0.1 (or 4.0.2, it's the debian unstable version) and boost 1.33.0 if the date_time include is uncommented.
Is there any known incompatibility between the two libraries ?
This appears to be the GCC 4.0 + SFINAE + anonymous enum problem discussed in this thread: http://lists.boost.org/Archives/boost/2005/08/91958.php.
This thread discusses vc7.1 -- not sure I see the connection unless you are saying gcc 4 has the same problem? [snip]
Gcc does have the problem; the title of the thread is misleading. See later posts such as: http://lists.boost.org/Archives/boost/2005/08/92002.php and http://lists.boost.org/Archives/boost/2005/08/92004.php For now it is SFINAE cannot be safely, portably used upon anonymous enums, though this could change, depending how we resolve core issue 488. - Mat
participants (5)
-
Brian Braatz -
Jeff Garland -
Jonathan Turkanis -
Mat Marcus -
tonton