Mold doesn't detect undefined symbols used in shared libraries

[Ulmo-F]

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()'`)

[rbartlensky]

I believe this is related to #526

[rui314]

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]

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]

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.