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 <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 <fcntl.h> header on this system (SuSE 11.?). They are available in the <unistd.h>… clearly a minor issue.
I was not enthused about modifying the source files in the boost tree, but adding the “#include <unistd.h>” 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 <boost/filesystem/v3/operations.hpp>
28-
29-# ifdef BOOST_POSIX_API
30-# include <fcntl.h>
31:# include <unistd.h>
32-# else // BOOST_WINDOWS_API
33-# include <windows.h>
Matt
Subject:
passing compiler directives
Date:
Mon, 23 Apr 2012 14:24:00 -0500
From:
Matt Priest <mpriest@cray.com>
To:
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 <fcntl.h>, 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.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users