I have a question about the behavior of
clang-linker-wrapper. For compiling an OpenMP offloading binary, I use e.g.
clang++ ... -Xoffload-linker-x86_64-unknown-unknown-elf -L<device_path> -L<host_path>
Here, the order is important, since I want
<device_path> being searched before
<host_path> during device linking.
Previously, this strategy worked for us, when we used
-Xopenmp-target=x86_64-unknown-unknown-elf -L<device_path> with an older version of LLVM. However, after merging current upstream changes to our code base and using the new driver, we need to use
-Xoffload-linker- AFAIK, since
clang-linker-wrapper is called to do the linking, and now our linking does not work as before since the order of flags is reversed.
clang-linker-wrapper gets the same order of linker flags as shown above, i.e., it is called like
clang-linker-wrapper ... --device-linker=x86_64-unknown-unknown-elf=-L<device_path> -L<host_path>
when it actually executes the link job for the device, the order is reversed and host flags appear before device flags as in
clang -o test.x86_64.native.img ... -L <host_path> -Wl,-L<device_path>
Due to this, the wrong libraries are found during device linking and our build does not work anymore.
My question is whether there is a special reason for the linker wrapper reversing the order of flags. Could this also be done as before, preserving the order?
Any help would be greatly appreciated.