Xen, Unless it's imperative for you that you build JDK 7, you might have more success with JDK 9. A lot have changed in the build system that may make it easier to build.
/Magnus > 4 maj 2017 kl. 08:38 skrev Xen <[email protected]>: > > David Holmes schreef op 04-05-2017 4:20: >> Hi Xen, >> Quite the adventure. >> Note that the options I suggested were all you should need, not >> options you need in addition to what you had attempted. And yes you >> need the symlinks to the simple names - gcc etc. >> You are building something that was never provided by the OpenJDK. >> There is no ARM version of OpenJDK in 7, or 8. There is an Oracle JDK >> version for ARM in 7 but that was for Java SE Embedded. So while I can >> provide the basic information I did about how we use cross-compilation >> to build for ARM it may be incomplete in your environment. You really >> should be talking to the IcedTea folk. >> You can try setting BUILD_HEADLESS_ONLY=true to avoid the need for an >> X11 headers etc but again I don't know if that will work for you. >> Generally even a headless JRE has to build in a headful environment. > > Yes, some of the patches I found in the IcedTea directory where the same or > similar as I had done :p. Notably the HOSTCC fix (they used CC_FOR_BUILD) and > perhaps something else. > > There was a patch for OpenEmbedded that would forego the need of X11 headers, > that I found, however upon trying it myself it didn't work at all. > > You wrote somewhere else in 2012 that BUILD_HEADLESS_ONLY hardly works > anymore; and that it would be better to use BUILD_HEADLESS instead. > > So I just went ahead to try to get those X11 headers (and libs) to build > against but this is quite a chore. > > There are like a zillion individual small libraries just like the linux folk > like to have 4k files in the filesystem max ;-). > > I use a DESTDIR because I got errors while not using it, but then e.g. libxcl > will use the pkgconfig of xcb-proto and search in the wrong location; -- > can't they just put it in one package lol. > > So you have to botch up the pkgconfig ... > > Oh, I didn't notice, libX11 completed. > > Apart from the fact that it installed in my own /usr/local... > > ;-). > > LDFLAGS to the rescue I guess, and properly using it (DESTDIR). > > As these things go, it now automatically compiles and installs xcb-proto, > libXau, libxcb, libX11, libffi and libasound :p. > > It's the search path not found errors that drive you insane though. > > For every header it needs it checks the path I supplied. > > Except for this one. > > And why, because it opens a pkgconfig file and looks no further. So here I > am, spending at least an hour trying to get one program to reference one file. > > Such a good ... spending of time. > > And then when it doesn't complain it's because it is actually loading the > file from my main system... > > So basically when I use a good prefix for my configurations other packages > won't be able to find it because the pkgtool shows a relative link relative > to sysroot, that they don't process. > > Then, the .la files also have the full absolute path on my own system. > > Then, the next library is going to actually process the .la paths based on a > sysroot directive I give it, creating overly long, nonexistent paths. > > So what I actually need to do is to botch up every pkgconfig file after the > fact so that it works for this system for absolute paths, while the .la files > are actually okay for those who use sysroot..... > > Now I am back with another library that is not found, and this pain just > keeps repeating itself. > > Sorry about this. > > > > > > > > > > > > > >> David >>> On 4/05/2017 7:31 AM, Xen wrote: >>> David Holmes schreef op 03-05-2017 6:07: >>>> For cross compilation you should need to set the following only: >>> So basically I know have a working HotSpot build for u101 but u131 and >>> u121 fail because a single cpp file references a variable that doesn't >>> exist anywhere in the source code. I know it means "MutableCallSite" >>> because it is referenced in java code but there is no other cpp or hpp >>> file that actually uses it. >>> Not that name of variable at least. >>> And u101 refuses to create the final executable correctly, I mean the >>> final liblvm.so. >>> So next up is u111b01 :p. >>> 111b01 succeeds in building but again cannot create the liblvm.so >>> So I had to add "rm -f $@; \" to the vm.make file and then I needed to >>> add -Xlinker -rpath=directory to my EXTRA_CFLAGS. >>> For linking against libffi.so.6 >>> And now the hotspot concluded :p. >>> Within seconds it ran into another library not found error this time >>> libjvm.so that it just created. >>> Am I doing something wrong with the directories? >>> In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded to >>> that, when clearly they were intended to be separate >>> I think I told it only to build a client vm but my target build dir >>> /lib/arm/client does not exist; is empty. >>> That server jvm is 121 MB :O. Is that because of debug information? >>> Okay, for some reason before it required -Xlinker -rpath and now it >>> requires -L... >>> Now it tries to add a copyright date notice to a small header file and >>> then add to it using build/tmp/java/java.nio/nio/genSocketOptionRegistry >>> but this program fails, saying: >>> Syntax error: word unexpected (expecting ")") >>> The problem is that it is trying to run an ARM executable on my build >>> host :). >>> :P. >>> This is going to take fundamentally forever, if I keep this up. >>> So the makefile was not correct, it only used HOST_CC in case of MacOS >>> platform. >>> I am going to apply those IcedTea patches I think.... >>> Now it uses the wrong AS. >>> My mistake, gcc actually uses the path to find an as that matches it, >>> which doesn't work in my case since I have overridden it. Proceeding again. >>> So I fixed the previous thing wrong and got a java compile error because >>> the file ended up empty after using the default "CC" CCFLAGS, obviously >>> that doesn't work so well when using HOST_CC. >>> Fixed again, now at last I get a normal error: libasound is not there >>> yet :p. >>> The errors that are supposed to happen. >>> Thankful errors :p. >>> Omg I should never have attempted this. >>> But anyway with libasound compiled I am further ahead again. >>> Now my biggest question: how can I create a true headless mode? >>> DO I need X11 headers persé? Can I just skip X11 compilation and awt >>> compilation? >>> Please? :P. >>> Regards.
