Repository navigation
Mold doesn't detect undefined symbols used in shared libraries #659
Description
First create a library with some missing implementation:
// Library.h
#pragma once
void f();
void g();
// Library.cpp
#include "library.h"
void f() {
g();
}
// void g() { }
Then use it in separate executable :
// main.cpp
#include "library.h"
int main() {
f();
return 0;
}
# CMakeLists.txt
project(test)
add_library(library SHARED library.cpp)
add_executable(main main.cpp)
target_link_libraries(main PUBLIC library)
Mold generates an unusable executable ./main: symbol lookup error: libLibrary.so: undefined symbol: _Z1gv.
I didn't find an option which could enable detection, but if there is one I tend to think it should be activated by default.
(On its side, GCC's linker does report libLibrary.so: undefined reference to g()'`)
Activity
rbartlensky commentedon Aug 23, 2022
I believe this is related to #526
rui314 commentedon Aug 24, 2022
Yes, I think it's because mold doesn't try to resolve all symbols at link-time when linking an executable. We tried to implement it, but it turned out that that's not doable in a reliable manner, so I think it's unlikely that we'll implement it.
Ulmo-F commentedon Aug 24, 2022
Hmm, fine.
This means that mold generates - silently - an executable which cannot be executed.
GCC's linker detects this error, so it probably resolves all symbols.
How does this challenge your assertion "that's not doable in a reliable manner" ?
I mean, I have a limited knowledge on link subject, but can't we find a way to achieve this ?
rui314 commentedon Aug 25, 2022
In order to resolve all symbols, you need to find all shared object files from the system's library directories first. But there's no reliable way to do it; you can read
/etc/ld.so.conf, but that's not guaranteed to be the same library search paths as the executable will run with. Especially if you are doing a cross compilation, it is very tricky to know what the executable environment will be.