Boost C++ Libraries: Ticket #297: boost::filesystem::exists is broken on cygwin

david_abrahams — Tue, 17 Aug 2004 14:58:03 GMT

Logged In: YES
user_id=52572
Did you build your library with a cygwin-built bjam?  If you
build your library with a bjam built for Windows, you get
windows behavior, even under cygwin (so look for something
like "c:/cygwin/usr").  I'm not sure that Cygwin builds of the
filesystem library actually use the POSIX interface, but they
should.

libcw — Tue, 17 Aug 2004 15:14:26 GMT

Logged In: YES
user_id=780
Yes bjam was build with cygwin, as follows:
tar xzf boost-jam-3.1.10.tgz
cd boost-jam-3.1.10
./build.sh
cp bin.cygwinx86/bjam.exe "$INSTALL_PREFIX/bin"
And that is done with the following environment (in case
that matters)
TOOLS=gcc
PYTHON_ROOT=/usr
PYTHON_VERSION=2.3
GXX="$CXX"
GCC="$CC"
BOOST_SITE_CONFIG=/usr/src/boost/boost/boost/config/user.hpp
export TOOLS PYTHON_ROOT PYTHON_VERSION GXX GCC
BOOST_SITE_CONFIG
Other, more general environment variables are set too (like
CC, CXX and INSTALL_PREFIX).
I don't entirely understand your remark however, because the
boost code explicitely contains this code:
# if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX )
#   if defined(_WIN32) || defined(__WIN32__) ||
defined(WIN32) || defined(__CYGWIN__)
#     define BOOST_WINDOWS
#   else
#     define BOOST_POSIX
#   endif
# endif
at several place in the code, setting BOOST_WINDOWS
explicitely for __CYGWIN__.

beman_dawes — Wed, 30 Nov 2005 22:30:07 GMT

Logged In: YES
user_id=51042
I've finally tracked this down. It is a bug in the
Boost.Filesystem code.
To get the desired cygwin behavior, two things are required.
The cygwin supplied POSIX API has to be used, and slash
(rather than back-slash) has to be given as the root
directory. IOW, cygwin gives different meanings to root
paths depending on the initial character. Since the Boost
code converts slashes to back-slashes, the cygwin libraries
never see the slash.
The problem has now been fixed in the i18n branch code that
will be the basis for 1.34.0. Fixing it in the pre-i18n code
from 1.33.1 is difficult because the changes would need to
be spread between the class declaration in the header and
the implementation in the library. That is a recipe for
disaster since a crash would result if user code defined the
controlling macro one way but the library was built with it
defined the other way. So I won't make any change to the
1.33.x codebase. The branch code is scheduled to be merged
into the main trunk next week in any case.
--Beman

status changed

beman_dawes — Wed, 30 Nov 2005 22:30:08 GMT

status assigned → closed