I need to learn how to do that, but I will get to it within a week... Thanks From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeffrey Lee Hellrung, Jr. Sent: Tuesday, April 24, 2012 1:11 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] passing compiler directives On Tue, Apr 24, 2012 at 10:42 AM, Matt Priest mailto:mpriest@cray.com> wrote: Hello, I'm not sure if this is the standard etiquette for this mailing list, but I thought I would follow up on solution I found for this issue. Maybe it's of value to someone. You might want to file a trac ticket under the FileSystem library so Beman doesn't miss it. Well, also, before doing that, check that the same problem still exists in 1.49.0, too. I had assumed that the required dependencies needed by the source file, unique_path.cpp, weren't getting there because of an inability to get the location to the compiler. It turns out that "read" and "close" aren't available via the header on this system (SuSE 11.?). They are available in the ... clearly a minor issue. I was not enthused about modifying the source files in the boost tree, but adding the "#include " fixed the issue. Recompiling and adding the Bzip libs/header resulted in 1014 targets built with no "fail" messages. Here was the edit to "libs/filesystem/v3/src/unique_path.cpp", line #31: 27-#include 28- 29-# ifdef BOOST_POSIX_API 30-# include 31:# include 32-# else // BOOST_WINDOWS_API 33-# include Matt Subject: passing compiler directives Date: Mon, 23 Apr 2012 14:24:00 -0500 From: Matt Priest mailto:mpriest@cray.com To: mailto:boost-users@lists.boost.org Hello, In advance, please excuse this newbie question. I am trying to build boost_1_48_0 and it is going well for all but 4 targets, two of which are the disclaimed <iostreams> failures relating to the bzip targets. However, I'm getting errors when trying to build : boost_1_48_0/libs/filesystem/v3/src/unique_path.cpp Here's the error (there's a nearly duplicate error for the statically linked target): gcc.compile.c++ /users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o libs/filesystem/v3/src/unique_path.cpp: In function 'void {anonymous}::system_crypt_random(void*, std::size_t, boost::system::error_code*)': libs/filesystem/v3/src/unique_path.cpp:68:49: error: 'read' was not declared in this scope libs/filesystem/v3/src/unique_path.cpp:71:17: error: 'close' was not declared in this scope libs/filesystem/v3/src/unique_path.cpp:79:13: error: 'close' was not declared in this scope "gcc" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64 -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG -I"." -c -o "/users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o" "libs/filesystem/v3/src/unique_path.cpp" ...failed gcc.compile.c++ /users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o... It seems like a simple include file availability issue or a pre-processor define issue, but I can't seem to affect a change in that compiler command through the user-config.jam file edits. When I run b2 with --debug-configuration option, I clearly see that change the -L and -I options in the user-config.jam file is reflected in the output, but still only see the -I"." option as shown above. It seems to me that those functions, read and close, should be made available through including the usual , and I think it's a bit curious that no other targets fail from the lack of "read" and "close". Any insight would be appreciated... thank you. Matt _______________________________________________ Boost-users mailing list Boost-users@lists.boost.orgmailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users