New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mold 1.1 failed to find libraries with gcc 11.2.0 on riscv64 #358
Comments
On all the other platforms I know of, gcc always passes all paths required for linking, so I think this is gcc's bug. mold (and LLVM lld) do not have the notion of "default search paths" by design. They only relies on command line arguments, so as long as you pass the exact same arguments, they are guaranteed to produce the same results. That makes cross compilation pretty easy. |
I reported this issue to gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708 |
I have the same issue on ARM32 and can't really tell who should fix it. It appears that I suppose either |
We shouldn't add the notion of "default search paths" to mold for the sake of build reproducibility. Currently, it is guaranteed that mold produces the exact same output as long as you pass the same command line options and the same input files. That reproducibility is guaranteed across platforms, which makes cross building easy. We should fix GCC instead. |
for some reason gcc assumes all linkers should search for libraries in /lib and /usr/lib and deliberately skips them when constructing linker command line. this assumption does not apply to mold though and does not seem reasonable in general hence drop this logic and pass unfiltered LIBRARY_PATH to linker see: rui314/mold#358 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
gcc delibrately filters out default library paths, causing some linkers like mold fails to find libraries. This patch is a workaround and will be proposed for upstream soon. See-also: rui314/mold#358 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
gcc delibrately filters out default library paths when invoking linkers, causing some linkers like mold fails to find libraries. This patch is a workaround and will be proposed for upstream soon. See-also: rui314/mold#358 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
gcc delibrately filters out default library paths when invoking linkers, causing some linkers like mold fails to find libraries. This patch is a workaround and will be proposed for upstream soon. See-also: rui314/mold#358 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
Currently
gcc
(version 11.2.0) behaves differently on x86-64 and riscv64 platforms. The riscv64 version ofgcc
doesn't pass enough search dirs (such as/lib
,/usr/lib
) to mold, resulting in library resolution failure.Tested on Arch Linux RISC-V:
gcc
works well withbfd
:But with clang 13.0.1, mold works correctly because clang does keep library search path full:
I've found that
mold
will add default library paths for macho files whennostdlib
is not presented. Maybe we need to do the same thing on riscv64 platform?The text was updated successfully, but these errors were encountered: