undefined reference to `pthread_mutex_lock` and `halide_malloc`

[janakiramreddy3]

I am trying to run a simple halide program on riscv-64 baremetal target. I am able to compile the kernel using target string riscv-64-noos-rvv-vector_bits_128. but got below errors while linking with my main.cpp

undefined reference to pthread_mutex_lock undefined reference to pthread_mutex_init undefined reference to pthread_cond_init undefined reference to pthread_cond_wait undefined reference to pthread_mutex_unlock undefined reference to pthread_cond_signal undefined reference to pthread_create undefined reference to dlopen undefined reference to dlsym

undefined reference to halide_malloc undefined reference to halide_free undefined reference to halide_print

[mcourteaux]

This is desired behaviour. When you specify noos (i.e., no operating system), halide won't assume any os-specific runtime functions. This means it's your responsibility to provide them. On Linux, you could link with pthreads and dl. Afterwards you'd still need to specify the halide_* functions yourself.

Have a look at the runtime modules that get compiled into your pipeline when you specify noos:

https://github.com/halide/Halide/blob/a397712d3e6786f593a1e0f8ea8170d6363e97be/src/LLVM_Runtime_Linker.cpp#L1029-L1045

Pay attention to that comment: https://github.com/halide/Halide/blob/a397712d3e6786f593a1e0f8ea8170d6363e97be/src/LLVM_Runtime_Linker.cpp#L1030-L1034

Alternatively, specify an OS. Either way, Halide will need these functions, because you have features in your pipeline that require them. Perhaps, you could try to reduce the surface of functions you need to provide. For example, specify -no_asserts to get rid of asserts (very much NOT recommended) (and their implied printing) and get rid of all multithreading (async()/parallel()).

Note that it's also possible to use -no_runtime for all your pipelines, and generate one runtime separately (with the AOT generator flag -r), which you link to your application, to avoid having all the runtime functions be included in every pipeline you compile. This is how I recommend working in serious projects with many pipelines.

[janakiramreddy3]

@mcourteaux Thank you so much for your detailed explanation. It helped me understand the issue, thanks for your time and support!