Behavior difference of 32-bit and 64-bit libraries

[lcarreon@…]

Hi,

I have built the 32-bit and 64-bit versions of the Boost libraries on Solaris 10 x86. I specified the following options when I built the libraries:

runtime-link=shared

link=shared

Now, I'm trying to experiment with the libraries and I'm observing some inconsistency.

I wrote the program test_space.cpp to display the space information about the current filesystem using version 3 of the Boost filesystem library.

When I run the 32-bit version of test_space.cpp, I get the following results:

capacity = 33666173952

free = 0

available = 33410671616

When I run the 64-bit version of test_space.cpp, I get the following results:

capacity = 33666173952

free = 33410000896

available = 33073339392

Based on the above results, it seems that the 32-bit version is not behaving correctly. Am I missing something here?

Here's another observation I have. I wrote another program test_direntry.cpp to display the file type of three paths again using version 3 of the Boost filesystem library.

When I run the 32-bit version of test_direntry.cpp, I get the following results:

An unknown path:

dummy status is file not found

A file path:

bin-soli32/test_direntry status is type unknown

A directory path:

/home/Leo/Devel/projects/compiler_tests/test_direntry status is type unknown

When I run the 64-bit version of test_direntry.cpp, I get the following results:

An unknown path:

dummy status is file not found

A file path:

bin-soli64/test_direntry status is regular file

A directory path:

/home/Leo/Devel/projects/compiler_tests/test_direntry status is directory file

It appears from the above results that the 32-bit version of test_direntry.cpp isn't behaving correctly. Do you have an idea what I could have done wrong or is this a bug in the library?

Regards, Leo

[lcarreon@…]

Additionally, when I re-run the 32-bit version of test_space.cpp it core dumps. According to the Sun Studio 12.2 IDE debugger, the core dump is occuring on lines 431-432 of the file boost/filesystem/v3/operations.hpp. These two lines contain the following:

inline space_info space(const path& p) {return detail::space(p);}

[lcarreon@…]

Another inconsistency that I discovered is the behavior of the directory_iterator class.

I have attached test_diriterator.cpp which is the test program I used and discovered this inconsistency.

When I run the 32-bit version of test_diriterator.cpp, I get the following result (spacing added):

"/home/Leo/Devel/projects/compiler_tests"

"/home/Leo/Devel/projects"

"/home/Leo/Devel"

"/home/Leo"

"/home"

"/"

""

""

""

""

""

""

""

""

""

When I run the 64-bit version of test_diriterator.cpp, I get the following result (spacing added):

"/home/Leo/Devel/projects/compiler_tests/Makefile.mak"

"/home/Leo/Devel/projects/compiler_tests/test_builtins"

"/home/Leo/Devel/projects/compiler_tests/test_direntry"

"/home/Leo/Devel/projects/compiler_tests/test_diriterator"

"/home/Leo/Devel/projects/compiler_tests/test_errorcode"

"/home/Leo/Devel/projects/compiler_tests/test_locales"

"/home/Leo/Devel/projects/compiler_tests/test_mktime"

"/home/Leo/Devel/projects/compiler_tests/test_path"

"/home/Leo/Devel/projects/compiler_tests/test_rdiriterator"

"/home/Leo/Devel/projects/compiler_tests/test_space"

"/home/Leo/Devel/projects/compiler_tests/test_statvfs"

"/home/Leo/Devel/projects/compiler_tests/test_typeid"

"/home/Leo/Devel/projects/compiler_tests/test_tzset"

It appears that the 32-bit version is displaying the result of path.remove_filename() instead. Would appreciate your comments.

[lcarreon@…]

I have figured out the cause of the problems stated above. It is the line #35 of the file boost_1_45_0/libs/filesystem/v3/src/operations.cpp. This line contains the following:

#define _FILE_OFFSET_BITS 64 at worst, these defines may have no effect,

If the intention of this line is to support large files (files greater than 2GB in size), the recommended alternative according to Solaris documentation is to define _LARGEFILE64_SOURCE. This compiler option switches file support from 32-bit to 64-bit on a 32-bit environment.

For the moment, I simply commented out the line for my 32-bit Solaris x86 build.

[Beman Dawes]

I'm going to need to see the output config_info for both your 32-bit and 64-bit environments. You will need to run something like this:

cd boost-root/libs/config/test bjam config_info

If bjam isn't in your path, you will need to specify its directory.

bjam should produce a file named config_info.output, probably in boost-root/bin.v2/libs/config/test/config_info.test/sun/debug/stdlib-sun-stlport. That path will vary accordingly if you are using a different standard library or a different compiler.

More information is needed about the configuration to figure out what the #if's should look like for Solaris. We don't want to break configurations like the Sandia test machine, when the large file test already passes.

Thanks,

--Beman

[lcarreon@…]

Hi,

I'm on an overseas trip at the moment. I will supply the info that you requested as soon as I get back home.

Regards,

Leo

[lcarreon@…]

Hi,

I'm attaching the two files that you requested.

Regards, Leo

[lcarreon@…]

ZIP file that contains the config_info.output for 32/64-bit Solaris x86

[Leo Carreon <lcarreon@…>]

Hi,

Just wanted to find out if the information that I supplied was of any help?

Regards,

Leo

[willchido@…]

Hello, I have been seriously affected by this bug as well. I would like to report that it appears fixed in 1.47. Apparently, the changes made to fix QNX for that release also fixed Solaris.

May I please wonder aloud how on Earth the filesystem bugs for QNX get addressed before the Solaris ones?

[Leo Carreon <lcarreon@…>]

Hi,

It appears that this problem has been fixed in Boost 1.47.0 thus this ticket may be closed.

Kind regards, Leo

[Beman Dawes]

17. May I please wonder aloud how on Earth the filesystem bugs for QNX get addressed before the Solaris ones?

1. Someone bothers to run public regression tests for QNX. No one bothers for Solaris. See http://www.boost.org/development/tests/develop/developer/summary.html

Likewise, QNX patches get contributed occasionally, but this is rare for Solaris.

Anyhow, the reported problems have been fixed so the issue is being closed.

Thanks,

--Beman