Encoding problem when building
dingxmin at linux.vnet.ibm.com
Fri Jan 4 05:29:32 UTC 2013
I investigated how local specific characters get into generated
sources in corba module. Those classes are generated by following
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m
-J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -td
"../../../../src/share/classes/org/omg/PortableInterceptor" -corba 3.0
-fall -pkgPrefix PortableServer org.omg
I checked idlj help but there is no encoding specific option. My
locale environment vars are listed below
Could you give me any hint about how to force idlj to generate ascii
On 1/1/2013 12:47 AM, Kelly O'Hair wrote:
> In the past, the "-encoding ascii" was important, all the reasons I can't completely list right now. But it is important
> that regardless of the locale, the bits created during the build should be the same for everyone.
> The definition of "same" might not be bit for bit, but by minimizing the potential differences we have a fighting
> chance of measuring "the same".
> But my question is, how are any locale specific characters getting into generated sources? That's what we need to find out.
> Removing "-encoding ascii" is probably not the right answer, and if it is, will require some debate.
> On Dec 30, 2012, at 9:25 PM, Frank Ding wrote:
>> I have an encoding problem when building openjdk 8 on my Windows 7. My windows is Chinese environment but I exported LANG=C in cygwin bash before building. The issue is that in module corba and jdk, some java classes are generated by program. They happen to contain Chinese characters in comment. However, they are compiled with explicit option "-encoding ascii" in makefile. This results in unrecognizable chars complained by javac (Error: encoding ascii unmappable chars) . I have a patch that removes all unnecessary "-encoding ascii" but I am not sure all its side effect. Shall I submit a bug?
>> Best regards,
More information about the build-dev