getting toolchain to be used

[Magnus Ihse Bursie]

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 <list at xenhideout.nl>:
> 
> 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.