Khi biên dịch chéo thư viện libiconv cho HarmonyOS PC, tôi gặp lỗi liên kết glibc kỳ lạ mặc dù cấu hình có vẻ chính xác. Nguyên nhân hóa ra là do libtool loại bỏ tham số --target trong giai đoạn liên kết. Đây là xung đột giữa công cụ những năm 90 và Clang hiện đại, giống như "Tam giác quỷ Bermuda" của việc chuyển đổi HarmonyOS.

Tại sao các bản biên dịch chéo với GCC trước đây không gặp vấn đề này mà Clang lại gặp?

Không phải bộ công cụ bị hỏng, mà là Clang quá "linh hoạt".

• Bộ công cụ GCC truyền thống (ví dụ: aarch64-linux-gnu-gcc): Tham số --target được mã hóa cứng trong tệp nhị phân, nên bạn có thể chạy trực tiếp.
• Clang/LLVM: Một tệp nhị phân hỗ trợ nhiều kiến trúc. Do đó, việc chỉ định rõ ràng --target là bắt buộc khi biên dịch chéo với Clang.

Đây không phải lỗi của bộ công cụ, mà là do Clang là một trình biên dịch đa năng (Cross-Capable Compiler), hành vi mặc định và đường dẫn tìm kiếm liên kết của nó liên quan nhiều đến môi trường máy chủ (Host).

Lỗi khi biên dịch chéo thư viện libiconv với HarmonyOS SDK (minh họa):

ld.lld: cannot find crti.o: No such file or directory
ld.lld: cannot find -lgcc
ld.lld: cannot find -lc

Thông báo lỗi cho thấy libtool sử dụng clang để biên dịch chéo, nhưng liên kết ld.lld không tìm thấy tệp musl runtime (như crti.o), mà thay vào đó lại cố gắng liên kết các thư viện GCC (như -lgcc, -lc). Điều này cho thấy liên kết không nhận dạng đúng môi trường musl.

Đây là một "bẫy" kinh điển trong biên dịch chéo. Vấn đề không phải do thao tác của bạn, mà là do libtool có sự khác biệt lớn với các trình biên dịch hiện đại như Clang.

1. Bản chất vấn đề: Sự xung đột giữa hai thế hệ công cụ

1.1 Sự khác biệt cơ bản giữa Clang và GCC

Đặc điểm	Bộ công cụ GCC truyền thống	Bộ công cụ Clang hiện đại
Thiết kế nhị phân	Mã hóa cứng một mục tiêu (arm-linux-gnueabi-gcc)	Đa mục tiêu, dùng chung (clang --target=)
Liên kết thư viện chuẩn	Tích hợp sẵn đường dẫn glibc	Phụ thuộc vào tham số rõ ràng
Chế độ biên dịch chéo	Tự động nhận dạng qua tiền tố	Cần khai báo thủ công nền tảng đích

1.2 Tái hiện hiện tượng: Tại sao liên kết đến glibc máy chủ?

Khi chạy ./configure --target=aarch64-linux-ohos, các bước tiềm ẩn:

• libtool: Nhận dạng nền tảng dựa trên tiền tố tên trình biên dịch (không hiểu --target).
• Clang: Yêu cầu rõ ràng --target, --sysroot, -fuse-ld=lld.
• Xung đột: libtool bỏ qua hoặc mất tham số --target trong giai đoạn liên kết.

1.3 Mâu thuẫn trung tâm

• Hạn chế của libtool: Nhận dạng nền tảng đích qua tiền tố tên tập tin trình biên dịch (ví dụ: arm-linux-), không thể phân tích tham số --target.
• Tính năng hiện đại của Clang: Cần chỉ định rõ ràng bộ ba tham số: --target, --sysroot, -fuse-ld=lld.
• Bỏ qua tham số: Ngay cả khi bạn chỉ định bộ ba, libtool vẫn làm mất tham số trong giai đoạn liên kết.

2. Giải pháp chuyên sâu: Chiến lược phòng thủ bốn lớp

2.1 Phương án 1: Truyền tham số qua -Wc, (Khuyến nghị)

./configure \
  CC="clang" \
  CFLAGS="-Wc,--target=aarch64-linux-ohos \
          -Wc,--sysroot=${OHOS_SYSROOT} \
          -Wc,-fuse-ld=lld" \
  LDFLAGS="-Wc,--target=aarch64-linux-ohos \
           -Wc,--sysroot=${OHOS_SYSROOT}" \
  --host=aarch64-linux-ohos

Bản chất kỹ thuật:

• -Wc, là cơ chế đường hầm tham số của libtool (định dạng: -Wc,<arg>).
• Có thể phân tách nhiều tham số bằng dấu phẩy: -Wc,--target=xxx,-mfloat-abi=softfp.
• Phải bao phủ toàn bộ quy trình: Đồng thời cấu hình trong CFLAGS (biên dịch) và LDFLAGS (liên kết).

Ưu điểm: Không cần sửa đường dẫn hệ thống, tương thích với logic phân tích của libtool, thân thiện với CI/CD.

2.2 Phương án 2: Tạo bí danh trình biên dịch (tương thích truyền thống)

# Tạo bí danh phù hợp với quy tắc đặt tên của libtool
sudo ln -s ${OHOS_CLANG} /usr/bin/aarch64-linux-ohos-clang
./configure CC=aarch64-linux-ohos-clang --host=aarch64-linux-ohos

2.3 Phương án 3: Gộp biến CC (dự phòng khẩn cấp)

./configure \
  CC="clang --target=aarch64-linux-ohos --sysroot=${OHOS_SYSROOT}" \
  HOST_CC=gcc \  # Bắt buộc chỉ định trình biên dịch máy chủ
  --host=aarch64-linux-ohos

2.4 Phương án 4: Chuyển sang CMake (Giải pháp tối ưu)

# toolchain-ohos.cmake
set(CMAKE_C_COMPILER "clang")
set(CMAKE_C_COMPILER_TARGET "aarch64-linux-ohos")
set(CMAKE_SYSROOT "$ENV{OHOS_SYSROOT}")
set(CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld")

3. Kỹ thuật sâu: Tại sao cần bộ ba tham số?

3.1 Vai trò cốt lõi của --target

--target=aarch64-linux-ohos

• ABI và tập lệnh: Chỉ định kiến trúc ARMv8 (aarch64).
• Định danh hệ điều hành: linux-ohos khai báo nền tảng HarmonyOS.
• Loại thư viện chuẩn: Ngụ ý sử dụng musl libc (mặc định của HarmonyOS).

3.2 Sự cần thiết của --sysroot

--sysroot=/opt/ohos-sdk/native/sysroot

Đường dẫn	Nội dung
$SYSROOT/usr/include	Tệp tiêu đề musl
$SYSROOT/usr/lib	Tệp khởi động như crt1.o

3.3 Tính không thể thay thế của -fuse-ld=lld

-fuse-ld=lld
# Hiện tại fuse-ld có thể không hoạt động, khuyến nghị sử dụng:
LDFLAGS="--ld-path=${LD} --target=${TARGET_PLATFORM} --sysroot=${SYSROOT} -fuse-ld=lld"

• GNU ld không nhận dạng cấu trúc đường dẫn thư viện của HarmonyOS.
• LLD (LLVM linker) hỗ trợ nguyên bản hệ thống mục tiêu của Clang.

4. Chẩn đoán thực tế: Xác định libtool mất tham số

4.1 Bật log chi tiết

export LIBTOOL_DEBUG=1  # Bật debug nội bộ của libtool
make VERBOSE=1          # Hiển thị lệnh đầy đủ

4.2 Phân tích log chính

Nếu thấy đường dẫn máy chủ, ví dụ:

libtool: link: clang -o program ... /usr/lib/x86_64-linux-gnu/libc.so

Điều này cho thấy --target chưa được áp dụng.

4.3 Sửa ô nhiễm đường dẫn thư viện

# Loại bỏ ô nhiễm lịch sử
find . -name "*.la" -exec sed -i "s|/usr/lib/x86_64-linux-gnu||g" {} \;

# Thiết lập đường dẫn tìm kiếm riêng cho libtool
export LT_SYS_LIBRARY_PATH="${OHOS_SYSROOT}/usr/lib"

5. Gợi ý cuối cùng

• Dự án hiện có: Sử dụng kết hợp truyền tham số qua -Wc, và LT_SYS_LIBRARY_PATH.
• Dự án mới: Bắt buộc sử dụng CMake kết hợp với bộ công cụ tiêu chuẩn HarmonyOS NDK.
• Kiểm tra sâu: Chạy file libiconv.so | grep "ARM aarch64" để xác nhận định dạng ELF.

Kịch bản xác minh đầy đủ:

#!/bin/bash
# Xác minh libiconv không liên kết với glibc
${OHOS_READELF} -d ${ICONV_INSTALL_PATH}/lib/libiconv.so | grep NEEDED

# Đầu ra kỳ vọng:
#  0x0000000000000001 (NEEDED) Shared library: [libc.so]
#  0x0000000000000001 (NEEDED) Shared library: [libm.so]

Khi bạn thấy libc.so của musl thay vì libc.so.6 của glibc, bạn đã vượt qua "Tam giác quỷ Bermuda" của việc chuyển đổi HarmonyOS.