Hi, guys,
unfortunately, not many of the current AWT engineers can provide
valuable information on the wrapper generator. Many thanks to Yuri (in
CC), he digged up the following bug:
6185483: AMD64: xawt 32-bit build should not require running a 64-bit
executable
It's hidden on bugs.sun.com, unfortunately.
In a few words, on Solaris, we used to build single rt.jar for both 32-
and 64-bit platforms, because we couldn't have two rt.jar files in
solaris-i586 and solaris-amd64. So we had to build rt.jar on 32-bit
platform, which at that time lacked support for cross-compilation for
64-bits (Solaris 8, Solaris Studio 8 didn't support 64-bit code
generation for x86).
Another problem was that when we introduced support for solaris-amd64,
we followed the same pattern as with solaris-sparc/sparcv9. At the
promotion time, 32-bit image was copied over 64-bit one - that was fine
for sparc/sparcv9, as the files were actually the same, but different in
i586/amd64 case.
Decision was made to calculate 64-bit field offsets in advance and store
them in the workspace, so we can have 32/64 classes.
There was another discussion a few years ago about the same topic, but I
don't remember any details. Most likely we decided to leave sizes.64 as
is...
Given that we now build using SS12, we should check if we can drop
sizes.64 and calculate 64-bit offsets the same way as we do for 32-bits.
Thanks,
Artem
On 6/14/2012 3:01 PM, Magnus Ihse Bursie wrote:
On 2012-06-14 12:49, Artem Ananiev wrote:
Generation process include creating a new sizer.c file for each
structure described in "xlibtypes", compiling it and calling the
resulted binary to get offsets for all the structure fields.
How is this supposed to work when cross-compiling?
And why do you need to to this for another platform than the one we are
compiling for? (E.g., if we are generating a 64-bit macosx build, we
also do this for 32-bit macosx)
I don't remember the exact issue about Solaris-x64, why it's handled
separately and includes manual generation.
The information I was able to dig up indicated that the weirdness of how
this was compiled had caused breakage previously, and this was added as
some kind of regression test. (It was appearantly designed to catch the
error of compiling with 64-bit when 32-bit was intended, or vice versa
-- or something like that).
What are exact issues you observe with the wrapper generator?
Portability and cross-compilations issues. The main problem is: why is
it compiled for anything else than the build platform? If it is supposed
to just run on the build system, why do we need more than one? And if it
is supposed to run on the target system (!), then it will not work when
cross-compiling.
/Magnus
