I have been scratching my head over building openjdk-8 with multilib for an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the 64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc

The include file for openjdk-8-release-aarch32.inc sets:

COMPATIBLE_HOST = "^$"
COMPATIBLE_HOST_armv7ve = "arm"
COMPATIBLE_HOST_armv7a = "arm"

So this should theoretically work as it does when the recipe is built for native aarch32. Except that it does not in the multilib case. Although building for multilib the recipe includes openjdk-8-release-aarch64.inc instead of openjdk-8-release-aarch32.inc. If I force the recipe to include openjdk-8-release-aarch32.inc everything works fine, except, of course, that OpenJDK cannot be built for aarch64 anymore.

I am not too familiar with the inner workings of bitbake's multilib code. That's why I am looking here for assistance first before spending a lot of time digging through the code.

Thanks,
Rudi

On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:

I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc

I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard

On 1/26/21 11:35 AM, Richard Purdie wrote:

On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:

I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc

I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard

Thanks, Richard. That's what I thought it is. Essentially, the includes are, as expected, resolved at parse time of the recipes, which makes entirely sense. The include files themselves conditionally set SRC_URI for patchsets which are evaluated when the recipes eventually is executed. While the conditional include is neat for keeping things separate, a solution might be to combine the two include files into one.

Cheers,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700