Since the changeset touched makefiles, I've included
build-dev@openjdk.java.net .
I need to push the hsx24 bug asap. Please review it.
Thanks.
Tao
On 6/4/13 2:37 PM, Tao Mao wrote:
Hi all,
Need reviews to catch RDP2.
The current webrev is a working solution to all platforms, Linux,
Windows, and Solaris.
http://cr.openjdk.java.net/~tamao/7122222/webrev.00/
Thanks.
Tao
On 5/30/13 10:21 AM, Tao Mao wrote:
Included runtime dev to see whether they have some idea to handle the
compilation choices.
For now, it's been verified that the fix is functionally sufficient.
Thanks.
Tao
On 5/29/13 5:27 PM, Tao Mao wrote:
Thank you, Mikael.
Please see inline.
Reviewers, please review it based on the following new observation.
Tao
On 5/27/13 2:05 AM, Mikael Gerdin wrote:
Tao,
On 2013-05-25 02:19, Tao Mao wrote:
7ux bug
webrev:
http://cr.openjdk.java.net/~tamao/7122222/webrev.00/
changeset:
(1) make -D_FILE_OFFSET_BITS=64 only available to generating
ostream.o
Why conservative rather than making -D_FILE_OFFSET_BITS=64 globally
applicable?
Global setting of -D_FILE_OFFSET_BITS=64 on linux works fine;
however,
there are at least five code conflicts if introducing the flag
globally
to Solaris.
One was resolved as in os_solaris.inline.hpp, but the rest four files
had conflicts deep in c library. Even if they are excluded from
setting
-D_FILE_OFFSET_BITS=64, the compiled VM is corrupted.
(2) For now, no Windows solution.
I haven't found any clean solution for solving this problem on
Windows.
This seems like an insufficient fix if you can't make it work on
all platforms. I tried building with "-D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64" ons Solaris and hit an #error in libelf.h
saying it wasn't supported so I understand your problem there.
Yes, that's my grief :( you touched them, a bunch of them. That's
why I chose to apply the flag only to the files (ostream.cpp and
ostream.hpp) I want the effect.
Instead I suggest that you use the compatibility API described in
lf64(5) on Solaris. This API consists of fopen64, ftell64 and
friends and is exposed when "-D_LARGEFILE64_SOURCE" is set.
The same "-D_LARGEFILE64_SOURCE" is available on Linux and has the
added advantage of not changing any existing symbols and therefore
we can set the define for all files instead of just ostream
This approach has the added advantage that it more closely
resembles the changes which will be needed for Windows anyway.
Those changes would consist of changing calls to ftell/fseek to
64-bit versions and changing fopen to fopen64 on Solaris/Linux.
Both ways have pros and cons. The current implementation excludes
the usage of fopen64, providing portability (since there's no
fopen64 for Windows). Meanwhile, I understand your suggestion
provides other benefits.
This Sun White Paper
(http://unix.business.utah.edu/doc/os/solaris/misc/largefiles.pdf)
summarizes the usage of the flags on solaris (Page 5-26). And, it
should apply to Linux the same way as was agreed across platforms.
Since there is no fopen64 on Windows it seems that the default
fopen already supports large files.
I tested, and you are correct that the 32-bit VM on Windows can
write beyond 2GB (and beyond 4GB). Thank you, it's solved "half of
my problem" :)
/Mikael
test:
(1) Ability to write over 2g file for 32-bit builds were verified
on the
following configurations.
Linux * i586
Solaris * i586
Solaris * sparc
(2) Need a JPRT test for sanity check.
