AOSP dependencies: Search in architectural generic folder

[Paschalis Mpeis]

Problem

I am building a module that has only a 32 bit flavor, that is going to be used by another module. The compilation results go to the intermediate folder: `obj32`. The other module fails to meet the dependencies because it searchers on the generic `obj` folder instead of the `obj32`.

Example

Lets say that there exists an aosp module `foo`, that includes in its makefile:

    LOCAL_MULTILIB := 32

or 

    LOCAL_32_BIT_ONLY := true

A successful compilation of the module will place relevant intermediate files at:

    out/host/<host-os>/obj32

For example, export_includes file for intermediates will be at:

    out/host/<host-os>/obj32/SHARED_LIBRARIES/libfoo_intermediates/export_includes

And the library itself at:

    out/host/<host-os>/obj32/lib/libfoo.so

In a separate module, called `bar`, I include `foo`, however, compilation fails as it searches for dependencies at:

    out/host/<host-os>/obj

This folder is empty as everything related to `foo` was placed in `obj32` folder.

Question

How this can be solved? Is there a way to instruct `foo` to place output in the `obj` folder? Or is there a way to inform `bar` that `foo` is a 32 bits variant?

I also posted this question here.

Cheers,

Paschalis

[Colin Cross]

You can only link against libraries with the same ABI (32-bit or
64-bit) as the executable, so add LOCAL_MULTILIB := 32 to the bar
module.

> --
> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Building" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-buildi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Paschalis Mpeis]

Thanks for your help!

I 've got a follow up question, a bit more specific!

So let's say that module bar (that includes foo) is actually the libart module.

By executing 'lunch' and then picking a target like the shamu/Nexus 6, which is 32 bit, shouldn't have automatically set: LOCAL_MULTILIB := 32 ?

Cheers,

Paschalis

[Colin Cross]

lunch selects the device, but the paths above are for host modules.
The host always builds for 64-bit and 32-bit.

On Wed, Apr 27, 2016 at 9:22 AM, Paschalis Mpeis

[Paschalis Mpeis]

Okay so theoretically if I remove "LOCAL_MULTILIB := 32" from both foo and bar modules, then both variants will be built for both modules, and it should work.

Am I correct?

Thanks again, and I am truly sorry if you find these questions stupid!

[Colin Cross]

For libraries, no LOCAL_MULTILIB means build both variants as
necessary. For binaries and packages, no LOCAL_MULTILIB means to
build for the preferred architecture, which is usually 64-bit but can
be tweaked by global settings like HOST_PREFER_32_BIT.

On Thu, Apr 28, 2016 at 7:51 AM, Paschalis Mpeis