Quantcast

getting toolchain to be used

classic Classic list List threaded Threaded
9 messages Options
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

getting toolchain to be used

Xen
I understand that the build environment has changed since 1.7 but I am
trying to build 1.7 for an older Synology device.

I first succeeded in building it using OE but since the compiler and/or
libc used was too high for the platform I am now trying to do it using
the platform's toolchain.

Unfortunately it seems it is using my own host g++ instead of the
toolchain g++ when it ought to be using that one.

I have copied many options from those used by OE. The biggest difference
is that I am either using an older toolchain or I am not using -e.

But when currently I use -e it fails immediately due to probably some
variables being unset.

What is the best way to ensure it is using my proper toolchain?

here are some of the values I have defined:

export ALT_OBJCOPY=${TOOLDIR}/${prefix}objcopy
export ALT_STRIP=${TOOLDIR}/${prefix}strip
export ALT_CPP=${TOOLDIR}/${prefix}cpp
export ALT_GCC="${TOOLDIR}/${prefix}gcc -march=armv5e -marm
--sysroot=$SYSROOT"
export ALT_LD="$ALT_GCC"
export ALT_CXX="${TOOLDIR}/${prefix}g++ -march=armv5e -marm
--sysroot=$SYSROOT"
export ALT_CPP_FLAGS=-lstdc++
export ALT_CXX_FLAGS=-lstdc++
export BUILD_CC="$ALT_GCC"
export BUILD_LD="$ALT_GCC"
export BUILD_GCC="$ALT_GCC"
export BUILD_CXX="$ALT_CXX"
export HOST_CC=gcc
export CC_FOR_BUILD=$HOST_CC

with TOOLDIR being something like arm-none-linux-gnueabi/bin
and prefix being arm-none-linux-gnueabi-

The point is that it first gives some hpp errors with ints not being
long ints, and then later an error referencing a crt1.o file on my main
system.

which clearly indicates that my main g++ is being used.

I am using the same bootstrap as OE, which is 1.6.0.

I am not using the same PATH although that wouldn't matter in this sense
I believe.

This is because the "hosttools" are also in the path, just last.

And their directory of "native" tools doesn't contain any compilers.

So everything seems to be quite equivalent.

I added variables CC and CCC and CXX to that list now...

Now it does do something different! And appears to halt on conversion
errors (float to double, int to long, int to float, ...)

and I can't get it to honour any compiler flags...

Well with these changed CC/CCC/CXX values it just outputs more warnings,
ultimately I got the same errors, I fixed the first ones, now I get
again.

I used the wrong LD...

But it's still not using my own g++. Help?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

David Holmes
Hi Xen,

On 3/05/2017 7:09 AM, Xen wrote:
> I understand that the build environment has changed since 1.7 but I am
> trying to build 1.7 for an older Synology device.

The info below indicates you are trying to build for ARMv5. There is no
native build for ARMv5 so I assume you are trying to cross-compile

For cross compilation you should need to set the following only:

ARCH arm
ALT_COMPILER_PATH <path to your toolchain>
ALT_OPENWIN_HOME <path to X11R6 in your toolchain>
CROSS_COMPILE_ARCH arm
EXTRA_CFLAGS  <this is where you set things like -march=armv5e -marm>

the local toolchain will be used for things that need to be compiled and
executed locally as part of the build. HOST_CC should take care of that.

> I first succeeded in building it using OE but since the compiler and/or

Out of curiosity what is OE?

David
-----

> libc used was too high for the platform I am now trying to do it using
> the platform's toolchain.
>
> Unfortunately it seems it is using my own host g++ instead of the
> toolchain g++ when it ought to be using that one.
>
> I have copied many options from those used by OE. The biggest difference
> is that I am either using an older toolchain or I am not using -e.
>
> But when currently I use -e it fails immediately due to probably some
> variables being unset.
>
> What is the best way to ensure it is using my proper toolchain?
>
> here are some of the values I have defined:
>
> export ALT_OBJCOPY=${TOOLDIR}/${prefix}objcopy
> export ALT_STRIP=${TOOLDIR}/${prefix}strip
> export ALT_CPP=${TOOLDIR}/${prefix}cpp
> export ALT_GCC="${TOOLDIR}/${prefix}gcc -march=armv5e -marm
> --sysroot=$SYSROOT"
> export ALT_LD="$ALT_GCC"
> export ALT_CXX="${TOOLDIR}/${prefix}g++ -march=armv5e -marm
> --sysroot=$SYSROOT"
> export ALT_CPP_FLAGS=-lstdc++
> export ALT_CXX_FLAGS=-lstdc++
> export BUILD_CC="$ALT_GCC"
> export BUILD_LD="$ALT_GCC"
> export BUILD_GCC="$ALT_GCC"
> export BUILD_CXX="$ALT_CXX"
> export HOST_CC=gcc
> export CC_FOR_BUILD=$HOST_CC
>
> with TOOLDIR being something like arm-none-linux-gnueabi/bin
> and prefix being arm-none-linux-gnueabi-
>
> The point is that it first gives some hpp errors with ints not being
> long ints, and then later an error referencing a crt1.o file on my main
> system.
>
> which clearly indicates that my main g++ is being used.
>
> I am using the same bootstrap as OE, which is 1.6.0.
>
> I am not using the same PATH although that wouldn't matter in this sense
> I believe.
>
> This is because the "hosttools" are also in the path, just last.
>
> And their directory of "native" tools doesn't contain any compilers.
>
> So everything seems to be quite equivalent.
>
> I added variables CC and CCC and CXX to that list now...
>
> Now it does do something different! And appears to halt on conversion
> errors (float to double, int to long, int to float, ...)
>
> and I can't get it to honour any compiler flags...
>
> Well with these changed CC/CCC/CXX values it just outputs more warnings,
> ultimately I got the same errors, I fixed the first ones, now I get again.
>
> I used the wrong LD...
>
> But it's still not using my own g++. Help?
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

Xen
David Holmes schreef op 03-05-2017 6:07:

> ARCH arm
> ALT_COMPILER_PATH <path to your toolchain>
> ALT_OPENWIN_HOME <path to X11R6 in your toolchain>
> CROSS_COMPILE_ARCH arm
> EXTRA_CFLAGS  <this is where you set things like -march=armv5e -marm>

In the forest of options, I actually forgot some of those :p.

I am trying to compile headless though.

> the local toolchain will be used for things that need to be compiled
> and executed locally as part of the build. HOST_CC should take care of
> that.

Does the ALT_COMPILER_PATH needs access to regular files like "gcc"? The
toolchains of course all have "arm-linux-gnueabi-gcc" style paths.

I can create a directory with symlinked versions, actually I already
had.

I took the toolchain from Ubuntu 14.04, since it is the last to have a
glibc version (for arm) that will run on kernel 2.6.32. Not ideal
perhaps but the older one available is for 12.04, and haven't tested
that one yet.

Now it compiled a long time until it got a problem with a host tool.

./mkbc: 1: ./mkbc: Syntax error: word unexpected (expecting ")")

Which is a bit peculiar, but I expect it to be cause by improper setup?
We will soon find out :) :p.

I really don't know how ALT_COMPILER_PATH would magically allow it to
find a compiler like /usr/bin/arm-linux-gnueabi-g++-4.7, so I will go
ahead and symlink it anyway.

Some of these files are also sitting in /usr/arm-linux-genueabi and even
though they are identical... Euhm, yep, they are hardlinked :p.

Well everything seems to be fine but I still have the same error:

/toolchaindir/bin/g++ <long command> - <
/openjdk-7-jre/99b00-2.6.5-r6.1/icedtea-2.6.5/build/openjdk/hotspot/src/cpu/zero/vm/bytecodes_arm.def
|  ./mkbc - bytecodes_arm.s

./mkbc: 1: ./mkbc: Syntax error: word unexpected (expecting ")")

Yup I am still using the IcedTea distribution. Not sure if that would
botch things up.

Well downloading openjdk-7 update 131 now to see if it makes a
difference.

So there we go.

:).

It can't find the header <new>! That is so weird.

It includes -I/usr/arm-linux-gnueabi/include
in /usr/arm-linux-gnueabi/include/c++/4.7.3/ there is the file "new".

And yet it doesn't find it. Oops, my mistake. Then it needs another
header, this time from
/usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabi,

is this thing going to require an include for every header location?
Lol.

I guess they did that this way to separate armel from armhf.

Next up is a "mcp" variable reference in

/openjdk-7-u131/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp at line
37 that is nowhere else in the file.

So I downgraded to u101 and it went on, but now it cannot link libjvm.so
because a symlink to it already exists :/.

     rm -f libjvm.so.1; ln -s libjvm.so libjvm.so.1;
     [ -f libjvm.so ] || { ln -s libjvm.so libjvm.so; ln -s libjvm.so.1
libjvm.so.1; };

It's definitely missing a directory somewhere.

>> I first succeeded in building it using OE but since the compiler
>> and/or
>
> Out of curiosity what is OE?

Oh sorry, I thought it would be something standard. OpenEmbedded.
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

Xen
In reply to this post by David Holmes
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

David Holmes
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.

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.
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

Xen
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]>:
>
> 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.

Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

Xen
Magnus Ihse Bursie schreef op 05-05-2017 17:13:
> 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.

I suspected as such especially as there was already a configure in JDK
8, but for me the reason is that I like to stay low :p. Also I do not
know whether or not JDK 9 will not require more dependencies and
libraries, and higher versions of GCC to build?

I gave up a few days ago after I could not get libX11 to find a shared
library that was nothing other than sys/types sitting clearly in the
direction I gave it but now I don't remember if it was not looking for
sys/types instead of sys/types.h....

No, it is just looking for sys/types.h.

The issue is probably caused by the fact that it wasnts my main system
compiler for that.

But it has no way for me to specify flags for native vs. cross? The
annoyance always. Why can't they just...

Why can't they just list variables in ./configure for both types of
compiler, ffs....

If I compile JDK with my own /usr/include present it will keep linking
or at least including /usr/include/X11 all the time.

Most libraries don't have a HOSTCC for CC_FOR_BUILD in their config file
or they don't use it at all...

Now it can't find a file that is sitting at the exact location it says
it is searching unless it uses a --sysroot that I've not given it.

/bin/sed: can't read =/target/usr/local/lib/libXau.la: No such file or
directory
libtool: link: `=/target/usr/local/lib/libXau.la' is not a valid libtool
archive

Yay.

The problem is not so much JDK, the problem is these other libraries
that depend on pkgconfig that lies to them if I put it in a staging
directory and who won't actually use --sysroot to find anything when
they should.

That whole build system is basically broken and I don't know my ways
around it.

So yeah I have yet to solve the puzzle of:

- using DESTDIR will cause pkgconfig to have original, target filesystem
links
- packages don't actually use --sysroot when resolving the locations
taken from pkgconfig.

- they don't search anywhere else either when PKGCONFIG is found.
- it is often impossible to tell what values they want in
LIBRARY_NAME_LIBS or whatever to make it work without pkgconfig.

- the result is that you compile with full filesystem paths instead.

I really think I just have to run a script to fix pkgconfig paths to the
full paths of my host system, but it might not work for all of them....

- omg it finished. I just didn't use --sysroot anywhere. Maybe my error
has been...

I mean maybe when using --sysroot I have to explicitly specify relative
paths in -I, but it's not like the one I tested actually looked there.
Or used that.

So the JDK fails to build if it has access to /usr/include/math.h
because it shouldn't be using that one but the toolchain one instead.

So that means looking at the compiler command again.... see if all the
-I are included in the right way, etc..

I thank you for your suggestion.


Typically older versions just have less dependencies and might also be
smaller?

Regards.





>
> /Magnus
>
>> 4 maj 2017 kl. 08:38 skrev Xen <[hidden email]>:
>>
>> 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.
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: getting toolchain to be used

Xen
In reply to this post by Magnus Ihse Bursie
So seriously,

because the command line includes -I/usr/include

and because the toolchain directory /usr/arm-linux-eabi/include is
embedded in the toolchain,
and because --sysroot /usr/include is also a standard directory

it searches its full paramters first before it considers any standard
locations, even if those standard locations are actually supplied on the
command line.

So it will find /usr/include first before venturing into e.g.
$SYSROOT/usr/include.

Why? Well apparently because due to --sysroot /usr/include is no longer
a standard location, so it is considered first.

Isn't that freaking amazing, it just ignores your parameters because it
already knows about them.

It integrates them into its list and only after will it start sorting
them according to what it already knew.

Which is really just wrong behaviour, but anyway.

It should integrate after sorting and then use the first occurance in
the list.

So I can get around it yes.

If I just copy the headers to $SYSROOT/usr/local/include.fuckedup, then
it will work.

Symlinks also don't work because it will just readlink them :p.

Meanwhile --sysroot actually does not cause locations to be resolved
according to $SYSROOT.

So it's whole purpose is meaningless: it just causes important locations
to be searched last.

Neither full nor relative paths are resolved with regards to it. Why
have it then???

Maybe it works for libraries, I don't know.

Oh man...

I truly believe people make it harder on purpose. Not you, in this case
just GCC.

There are just people invested in making life harder for other people.

For example, why doesn't GCC or make just output a list of locations
that it searched in?

It would be so easy.

And save so much time.

But they don't do it.

They just give a non-descript error.

That you need fucking strace to diagnose.

Sorry for my language though.

Regards.
Loading...