(autotools) fix ld override when ld binary is not in the same directo…#6425
(autotools) fix ld override when ld binary is not in the same directo…#6425waruqi merged 2 commits intoxmake-io:devfrom
Conversation
| name = name:gsub("g%+%+$", "ld") | ||
| name = name:gsub("g%+%+%-%d+", "ld") | ||
| envs.LD = dir and path.join(dir, name) or name | ||
| local ld = find_tool("ld") |
There was a problem hiding this comment.
Using find_tool may find the system ld instead of the ld corresponding to the current package toolchain, which may break many packages, especially for some cross-compilation toolchains.
/sdk/bin/linux-arm-clang -> /sdk/bin/linux-arm-ld
now:
/sdk/bin/linux-arm-clang -> /usr/bin/ld
There was a problem hiding this comment.
right, maybe i can add the path of the compiler in the search directory list of find_tool, would it work ?
There was a problem hiding this comment.
no, It is difficult to keep the package toolchain consistent with the result of find_tool. I still recommend that all tool-related information be obtained from package:build_getenv, which can correctly obtain the sdk/bin path corresponding to clang/ld.
Therefore, I currently use the path file name replacement method to obtain ld under the corresponding toolchain sdk path.
There was a problem hiding this comment.
i changed it to only fallback on find_tool if , is it more acceptable ? we can't use package:build_getenv because the point here is that only ld work with autotools, when clang++ is set as ld, it doesn't generate .so for shared libraries
shared packages installation are broken when --sdk is set with a bin directory without ld binary
e.g when using llvm toolchain with --sdk, ld binary may not exists in the bin directory and result with a non-existent path which make autotools use clang++ as linker wich prevent .so to be generated