Failing to compile to openwrt

[itay-sho]

Describe the bug A clear and concise description of what the bug is.
Hey, I tried to bump ot-br-posix version it openwrt to latest commit in main.
it looks like the compilation fails due to the following:

/home/itay/git/openwrt-dev/staging_dir/toolchain-aarch64_generic_gcc-13.3.0_musl/lib/gcc/aarch64-openwrt-linux-musl/13.3.0/../../../../aarch64-openwrt-linux-musl/bin/ld.bfd: third_party/openthread/repo/src/core/libopenthread-ftd.a(infra_if.cpp.o): in function `ot::BorderRouter::InfraIf::DiscoverNat64Prefix() const':
infra_if.cpp:(.text+0xa0): undefined reference to `otPlatInfraIfDiscoverNat64Prefix'

To Reproduce Information to reproduce the behavior, including:

1. Git commit id
   b041fa5
2. IEEE 802.15.4 hardware platform
   irrelevant
3. Build steps
   openwrt build system, used predefined -D:

CMAKE_OPTIONS += \
        -DOT_BORDER_ROUTER=ON \
        -DOT_CHANNEL_MANAGER=ON \
        -DOT_CHANNEL_MONITOR=ON \
        -DOT_FIREWALL=OFF \
        -DOTBR_BACKBONE_ROUTER=ON \
        -DOTBR_BORDER_ROUTING=ON \
        -DOTBR_DNSSD_DISCOVERY_PROXY=ON \
        -DOTBR_DUA_ROUTING=ON \
        -DOTBR_MDNS=mDNSResponder \
        -DOTBR_NAT64=ON \
        -DOTBR_OPENWRT=ON \
        -DOTBR_REST=ON \
        -DOTBR_SRP_ADVERTISING_PROXY=ON \
        -DOTBR_SRP_SERVER_AUTO_ENABLE=ON \
        -DOTBR_TREL=ON

Plus, I added my own two, trying to guess what broke the compilation:

        -DOT_NCP_INFRA_IF=OFF \
        -DOT_SIMULATION_INFRA_IF=OFF \

Any ideas if something really broke here or there is just a compilation flag that I need to toggle?
In general openthread-br isn't working for me at the moment in openwrt's main branch,
I am trying upgrade it, and hopefully to understand and fix it and send a PR there in case needed.

My investigation led me to the following reply:
#2398 (comment)

in NCP support thread, and also specifically to the following PR:
https://github.com/openthread/openthread/pull/10638/files

just tried to toggle both for off hoping to mitigate the problem,
unfortunately without any success

7. Network topology

Expected behavior A clear and concise description of what you expected to happen.

Console/log output If applicable, add console/log output to help explain your problem.

Additional context Add any other context about the problem here.

[Irving-cl]

Hi @itay-sho,

Thanks for finding the issue and doing investigation. However I don't think it's related to openthread/openthread#10638. Note that openthread/openthread#10638 adds an NCP based version of otPlatInfraIfDiscoverNat64Prefix. And when building OpenWRT we are building a posix platform for OT. It shouldn't link to NCP based version of OT plat APIs at all.

I think the root cause is openthread/openthread#10566. After this PR, otPlatInfraIfDiscoverNat64Prefix will only be available when OPENTHREAD_CONFIG_NAT64_BORDER_ROUTING_ENABLE and OPENTHREAD_POSIX_CONFIG_NAT64_AIL_PREFIX_ENABLE are enabled. But in current posix CMakeLists.txt:

if(${CMAKE_SYSTEM_NAME} STREQUAL "Linux" AND NOT OT_TARGET_OPENWRT)                                                                                                                                                                                                                                                       
    target_compile_definitions(ot-posix-config                                                                                                                                                                                                                                                                            
        INTERFACE "OPENTHREAD_POSIX_CONFIG_NAT64_AIL_PREFIX_ENABLE=1"                                                                                                                                                                                                                                                     
    )                                                                                                                                                                                                                                                                                                                     
    target_link_libraries(openthread-posix PRIVATE anl)                                                                                                                                                                                                                                                                   
endif()

It seems that for OPENWRT platform OPENTHREAD_POSIX_CONFIG_NAT64_AIL_PREFIX_ENABLE is not enabled.

Per my understanding on PR openthread/openthread#10566, we may need to implement a customized version of otPlatInfraIfDiscoverNat64Prefix for openwrt platform. Or we should use the posix version? @superwhd Thoughts?

@itay-sho
As a temporary workaround, I think you can disable OT_NAT64_BORDER_ROUTING in your build by adding -DOT_NAT64_BORDER_ROUTING=OFF.

[itay-sho]

Thanks for the workaround!
At first, it didn't work for me but I've added -DOTBR_NAT64=OFF and managed to compile.

I will send a PR with those changes to openwrt, will keep get posted about the more robust solution.
and let me know if there's something I could help with.

[superwhd]

Per my understanding on PR openthread/openthread#10566, we may need to implement a customized version of otPlatInfraIfDiscoverNat64Prefix for openwrt platform. Or we should use the posix version? @superwhd Thoughts?

The current posix implementation of otPlatInfraIfDiscoverNat64Prefix depends on libanl. If OTBR can depend on libanl on OpenWRT, then it can use this implementation. Otherwise you have to implement a solution without depending on libanl.

[itay-sho]

Per my understanding on PR openthread/openthread#10566, we may need to implement a customized version of otPlatInfraIfDiscoverNat64Prefix for openwrt platform. Or we should use the posix version? @superwhd Thoughts?

The current posix implementation of otPlatInfraIfDiscoverNat64Prefix depends on libanl. If OTBR can depend on libanl on OpenWRT, then it can use this implementation. Otherwise you have to implement a solution without depending on libanl.

I did some investigations from my side:
as for openwrt's main branch, I think (but not certain) that libanl was supported on my openwrt test VM target (armsr/armv8/generic EFI boot, since my machine is an arm mac). my assumption relies on the fact that I didn't struggle on the problem I had on my real router:

While my router, which is an aarch64-based as well (Banana pi r4) had some missing parts:

1. first, I had to add avahi-client as a dependency while the 1st target didn't need that at all.
2. moreover, I had some compilation problems due to missing -lanl for ld. in order to workaround it, I had to add the flag -DOT_TARGET_OPENWRT=ON to the flags I have mentioned before.

I also saw this commit from 2022 in openwrt talking about supporting libanl and it was merged back then:
openwrt/openwrt#11559

So speaking of right now I understand that at least some of the targets doesn't support libanl, but I am not really sure why.