Kompilowanie wersji dla architektur 32- i 64-bitowych

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

System kompilacji obsługuje kompilowanie binarnych plików dla 2 architektur procesorów (32- i 64-bitowych) w ramach tej samej kompilacji. Ta kompilacja 2 docelowych elementów nazywa się kompilacja multilib.

W przypadku wbudowanych bibliotek statycznych i bibliotek udostępnionych system kompilacji do tworzenia plików binarnych dla obu architektur. Konfiguracja produktu (PRODUCT_PACKAGES) razem z grafem zależności określa, która aby pliki binarne były kompilowane i instalowane w obrazie systemu.

W przypadku plików wykonywalnych i aplikacji system kompilacji domyślnie tworzy tylko wersję 64-bitową, ale możesz zastąpić to ustawienie za pomocą zmiennej globalnej BoardConfig.mk lub zmiennej w zakresie modułu.

Określ drugą architekturę procesora i ABI

BoardConfig.mk zawiera poniższe zmienne służące do konfigurowania drugiego procesora architektura i interfejs binarny aplikacji (ABI):

• TARGET_2ND_ARCH
• TARGET_2ND_ARCH_VARIANT
• TARGET_2ND_CPU_VARIANT
• TARGET_2ND_CPU_ABI
• TARGET_2ND_CPU_ABI2

Przykładowy plik Makefile, który korzysta z tych zmiennych, znajdziesz tutaj: build/make/target/board/generic_arm64/BoardConfig.mk

W przypadku kompilacji z wieloma bibliotekami nazwy modułów w tabeli PRODUCT_PACKAGES są zakryte 32-bitowych i 64-bitowych plików binarnych, o ile są zdefiniowane przez kompilację systemu. W przypadku bibliotek podlegających zależnościom jest jest zainstalowana tylko wtedy, gdy wymaga jej inna 32- lub 64-bitowa biblioteka lub .

Jednak nazwy modułów w wierszu poleceń make obejmują tylko Wersja 64-bitowa. Na przykład po uruchomieniu lunch aosp_arm64-engmake libc kompiluje tylko 64-bitową bibliotekę libc. Do skompilować 32-bitową bibliotekę libc, musisz uruchomić make libc_32.

Definiowanie architektury modułów w Android.mk

Za pomocą zmiennej LOCAL_MULTILIB możesz skonfigurować kompilację na potrzeby wersji 32- i 64-bitowej oraz zastąpić globalną zmienną TARGET_PREFER_32_BIT.

Aby zastąpić zasadę TARGET_PREFER_32_BIT, ustaw LOCAL_MULTILIB na jedną z :

• both tworzy wersje 32- i 64-bitowe.
• 32 kompiluje tylko wersje 32-bitowe.
• 64 kompiluje tylko wersje 64-bitowe.
• first kompiluje tylko pierwszą architekturę (32-bitową na urządzeniach 32-bitowych i 64-bitową na urządzeniach 64-bitowych).

Domyślnie zasada LOCAL_MULTILIB nie jest ustawiona, a system kompilacji określa, które architekturę umożliwiającą opracowanie w oparciu o klasę modułu i inne Zmienne LOCAL_*, np. LOCAL_MODULE_TARGET_ARCH i LOCAL_32_BIT_ONLY.

Jeśli chcesz utworzyć moduł dla konkretnej architektury, użyj zmienne:

• LOCAL_MODULE_TARGET_ARCH – ustaw tę zmienną na listę architektur, takich jak arm x86 arm64. Jeśli budowana architektura znajduje się na tej liście, system kompilacji uwzględnia bieżący moduł.

• LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH – ta zmienna jest odwrotna do LOCAL_MODULE_TARGET_ARCH Jeśli budowana architektura to not oznacza to, że bieżący moduł jest uwzględniony w systemie kompilacji.

Istnieją też dodatkowe warianty tych dwóch zmiennych:

• LOCAL_MODULE_TARGET_ARCH_WARN
• LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN

System kompilacji ostrzega, jeśli bieżący moduł jest pomijany z powodu wymienionych architektur.

Aby skonfigurować flagi kompilacji dla konkretnej architektury, użyj zmiennych LOCAL_*, gdzie * to sufiks dla danej architektury, np.:

• LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
• LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
• LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,

Te zmienne są stosowane tylko wtedy, gdy kompilowana jest wersja binarna dla tej architektury.

Czasami łatwiej jest skonfigurować flagi na podstawie tego, czy plik binarny jest kompilowany na potrzeby 32- czy 64-bitów. Użyj funkcji LOCAL_* z sufiksem _32 lub _64, np.:

• LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
• LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
• LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,

Ustaw ścieżkę instalacji biblioteki

W przypadku kompilacji niebędącej kompilacją wieloplatformową możesz użyć polecenia LOCAL_MODULE_PATH, aby zainstalować bibliotekę w innej lokalizacji niż domyślna. Przykład: LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw

W przypadku kompilacji multilib należy jednak użyć opcji LOCAL_MODULE_RELATIVE_PATH:

LOCAL_MODULE_RELATIVE_PATH := hw

W tym formacie zarówno 64-, jak i 32-bitowe biblioteki są instalowane we właściwym miejscu.

Jeśli tworzysz plik wykonywalny zarówno 32-bitowy, jak i 64-bitowy, użyj jednego z następujące zmienne, by odróżnić ścieżkę instalacji:

• LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64 – określa zainstalowaną nazwa pliku.
• LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64 – określa ścieżkę instalacji.

Uzyskaj katalog pośredni dla plików źródłowych

Jeśli w kompilacji z wieloma bibliotekami generujesz pliki źródłowe $(local-intermediates-dir) (lub $(intermediates-dir-for) za pomocą jawnych zmiennych), nie działa wiarygodnie. To jest ponieważ źródła pośrednie są wymagane przez 32-bitowe i 32-bitowe Kompilacje 64-bitowe, ale $(local-intermediates-dir) wskazuje tylko jedną z między dwoma katalogami pośrednimi.

System kompilacji udostępnia specjalny katalog pośredni, przyjazny dla bibliotek wieloplatformowych, do generowania źródeł. Żeby pobrać poziom średniozaawansowany: w ścieżce katalogu, użyj funkcji $(local-generated-sources-dir) lub $(generated-sources-dir-for). Zastosowanie tych makr jest podobne do: $(local-intermediates-dir) i $(intermediates-dir-for).

Jeśli plik źródłowy zostanie wygenerowany w tym specjalnym katalogu i odebrany od LOCAL_GENERATED_SOURCES. Obsługiwany jest zarówno 32-, jak i 64-bitowy na podstawie kompilacji multilib.

Wskaż architekturę systemu gotowych celów binarnych

W kompilacji z wieloma zasobami nie można używać jednocześnie atrybutów TARGET_ARCH i TARGET_ARCH w połączeniu z TARGET_2ND_ARCH, aby wskazać architekturę systemu gotowego komponentu binarnych wartości docelowych. Zamiast tego używaj zmiennych LOCAL_* LOCAL_MODULE_TARGET_ARCH lub LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH.

Dzięki tym zmiennym system kompilacji może wybrać odpowiednie 32-bitowe wartości gotowy plik binarny, nawet jeśli pracuje nad 64-bitową kompilacją Multilib.

Jeśli chcesz użyć wybranej architektury do obliczenia ścieżki źródłowej dla wstępnie skompilowanego binarnego pliku, wywołaj funkcję $(get-prebuilt-src-arch).

Sprawdź, czy generowanie plików ODEX w wersji 32- i 64-bitowej

W przypadku urządzeń 64-bitowych Google domyślnie generuje zarówno 32-bitowy, jak i 64-bitowy format ODEX obrazu rozruchowego i wszystkich bibliotek Java. W przypadku plików APK domyślnie Google generuje pliki ODEX tylko dla podstawowej architektury 64-bitowej. Jeśli aplikacja została uruchomiona w procesach 32- i 64-bitowych, użyj funkcji LOCAL_MULTILIB := both, by upewnić się, aby były generowane zarówno 32-bitowe, jak i 64-bitowe pliki ODEX. Jeśli aplikacja ma jakikolwiek pakiet 32-bitowy lub 64-bitowych bibliotek JNI, flaga informuje też system kompilacji, że ma je uwzględnić.