----- Original Message ----- > ----- david.hol...@oracle.com skrev: >
snip... > > > 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. > What is this builddeps server? Is it something that's worth emulating elsewhere? Good to see progress on cross-compilation. > Sounds silly to cross compile from x64 to ia32, yes, but the command > above > 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. > > > 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. > It's not clear to me why it's a good idea to remove traces of the 'closed' JDK from the makefiles. Wouldn't this only cause more divergence and mean that the core OpenJDK makefiles aren't being tested as much? > > > > 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.) > So basically it now works like other autotools projects like gcc, where you run the configure in the source directory (src) from your build directory (build): $ mkdir build $ cd build $ ../src/configure $ make > > 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 > The configure script is generated using the autoconf tool and is pieced together by the insertion and expansion of various m4 macros. To change it, you alter configure.ac and then run autoconf. This was the focus of my last question, as having configure checked into the repository means that everyone has to be using the same autoconf to generate, to avoid superfluous changes. > //Fredrik > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
