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
