Hi Fredrik,
On 22/03/2012 5:05 PM, Fredrik Öhrström wrote:
----- david.hol...@oracle.com skrev:
It is still unclear to me how cross-compilation is to be set up.
You can cross compile from x64 linux to ia32 linux, with the following
commandline:
../autoconf/configure \
--host=i686-unknown-linux-gnu \
--with-builddeps-conf=/home/ohrstrom/jdk8/common/autoconf/builddeps.conf.example
\
--with-builddeps-server=buildtools.se.oracle.com/buildtools/openjdk \
--with-builddeps-dir=/home/ohrstrom/builddeps \
--with-jvm-variants=client,server
For those outside of Oracle, the builddeps server is not available, you have
to have i686-unknown-linux-gnu-gcc et al in your path, and drop the builddeps
options.
I couldn't access /home/ohrstrom either :(
I guess this needs to be taken up internally to see how this build-deps
stuff is to be setup, configured, and maintained. Something for M2 perhaps.
Sounds silly to cross compile from x64 to ia32, yes, but the command above
Not silly at all, we have an issue with that right now.
exercising everything that is needed for cross compilation. What remains
is to find the correct CC for compiling to/for the build platform (legacy name
HOSTCC),
in configure for the hotspot build. By running from x64 linux to ia32 linux, I
cheat since the
i686-unknown-linux-gnu-gcc works for the build platform as well.
Ok, so as Erik added we're not quite there yet - but the pieces are
lining up.
It is unclear to me how the src/closed and make/closed repositories
are supported/handled. Going forward much of what pertains to Oracle JDK
proprietary features, should be moved out of the OpenJDK repository in
my opinion.
The new makefiles do build the closed jdk, even though it has to use the current
totally broken way of injecting source code repositories smack in the middle of
the
openjdk sources.
Of course, there should be no trace of closed jdk code, neither in the
makefiles,
nor in the source code. And there is a solution for this in the configure
script,
ie the add/override source roots commands. But that potential solution is
irrelevant as long
as the open/closed source code repositories are structured the way they are.
Ok I see how src/closed is handled. What I can't see is how make/closed
is handled, or more specifically how we factor out proprietary details
into a distinct set of closed "makefiles".
Is there a cheat sheet for how to run configure? There are many
options
that seems completely irrelevant to what would normally be part of a
JDK
build; conversely some obvious flags seem to be missing eg
ALT_OUTPUTDIR.
You set the OUTPUTDIR by running the configure script from the outputdir,
then run make from the outputdir. This was explained during the tech talk
and the information was available to you as a pdf. (Since you refused to have
a paper version sent to you.)
Yes - Guilty as charged - I have a PDF somewhere. But it was a general
question for everyone's benefit.
Plus, if I run configure from common/makefiles that does not become the
outputdir, it instead creates a top-level build directory in the repo
(though config.log and config.status do pollute the current directory).
Is it intended that any single person actually understand the contents
of configure and need to edit it? It has strange contents (like
multiple
file copyright headers in places ???).
Reading the configure script is like reading the bytecode of a Java program
or reading the machine code generate from a c-compiler. Go ahead if you want
to, but most people would prefer to read the source. ie configure.ac
I'll take that as a "No". ;-)
common/makefiles/compress.post
common/makefiles/compress.pre
??? These are just weird. What role do they serve? Were they
autogenerated?
common/makefiles/uncompress.sed
??? what is this? Is it autogenerated? How do I know if I need to add
anything to it?
If you read the comments in the Makefile where these commands are put to use,
You will find in MakeBase.gmk that these tools are necessary to workaround
command line length limitations on platforms like Solaris and Cygwin.
Thanks for the pointer. It is not evident from the the webrev where/how
these get used.
Does this pertain only to the new javac server or is this a general
enhancement to javac for 8?
It is an enhancement for jdk8.
Why do I have to cd to common/makefiles ?
Because we want to keep the original makefiles in place, for the time
being. Thus the new build system does not affect the old build system at
all.
The question was why do I have to cd into common/makefiles to run the
configure script. I think the answer is "because if you are in
common/makefiles then a build directory will be created at the top-level
of the repo forest; otherwise the pwd will be treated as the intended
outputdir".
Thanks,
David
//Fredrik
