Skip to content

Linux: avoid using gold as the linker #282

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

Merged
merged 1 commit into from
Jul 8, 2025

Conversation

kleisauke
Copy link
Collaborator

I suspect this might be the reason of the SEGV in lovell/sharp@2cd2f84 on linux-arm64v8. It looks like multiple .init_array sections are included in the final binary, which probably won't work.

v1.2.0-rc.4:

$ readelf -WS sharp-libvips-linux-arm64v8/lib/libvips-cpp.so.8.17.1 | grep -E '(init_array|gold-version)'
  [22] .init_array       INIT_ARRAY      0000000000f2c918 f1c918 000258 08  WA  0   0  8
  [24] .init_array       INIT_ARRAY      0000000000f9c960 f8c960 000008 08 WAo  0   0  8
  [32] .note.gnu.gold-version NOTE            0000000000000000 ffb844 00001c 00      0   0  4

v1.2.0-rc.3:

$ readelf -WS sharp-libvips-linux-arm64v8/lib/libvips-cpp.so.8.17.0 | grep -E '(init_array|gold-version)'
  [22] .init_array       INIT_ARRAY      0000000000f1dd18 f0dd18 0001a8 08  WA  0   0  8
  [31] .note.gnu.gold-version NOTE            0000000000000000 ffb86c 00001c 00      0   0  4

This PR:

$ readelf -WS sharp-libvips-linux-arm64v8/lib/libvips-cpp.so.8.17.1 | grep -E '(init_array|gold-version)'
  [19] .init_array       INIT_ARRAY      0000000000ed8c28 ec8c28 000260 08 WAo  0   0  8

See also: rust-lang/rust#141748.

@kleisauke
Copy link
Collaborator Author

Ah, I just noticed this comment: rust-lang/rust#141750 (comment). So, we're likely encountering the same issue.

@lovell
Copy link
Owner

lovell commented Jul 8, 2025

Great, thanks, I've been investigating this too. Here's the stack trace I get when running on a ARM64 device, which kind of suggests the libvips type system hasn't been set up properly:

#0  0x0000ffffd70d075c in ?? () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#1  0x0000ffffd70d1448 in g_hash_table_lookup () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#2  0x0000ffffd70dd490 in ?? () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#3  0x0000ffffd70dd618 in ?? () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#4  0x0000ffffd6f72134 in ?? () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#5  0x0000ffffd6f72c5c in vips_object_get_type () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#6  0x0000ffffd6f779f0 in ?? () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#7  0x0000ffffd6f7925c in vips_image_get_type () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#8  0x0000ffffd6f95198 in vips_init () from /home/admin/sharp/src/build/Release/../../../node_modules/@img/sharp-libvips-linux-arm64/lib/libvips-cpp.so.8.17.1
#9  0x0000fffff7b33e58 in __pthread_once_slow (once_control=0xfffff5220c00, init_routine=0xa941f0 <__once_proxy@plt>) at ./nptl/pthread_once.c:116
#10 0x0000fffff51f428c in init(Napi::Env, Napi::Object) () from /home/admin/sharp/src/build/Release/sharp-linux-arm64.node
#11 0x0000fffff51f2d90 in napi_register_module_v1 () from /home/admin/sharp/src/build/Release/sharp-linux-arm64.node
#12 0x0000000000b4ad44 in napi_module_register_by_symbol(v8::Local<v8::Object>, v8::Local<v8::Value>, v8::Local<v8::Context>, napi_value__* (*)(napi_env__*, napi_value__*), int) ()

If this is the cause then this would also explain why I couldn't get gcc 10 to work with rust nightly on x64. (It failed at compile time, whereas we're seeing the ARM64 build fail at runtime.)

@lovell lovell merged commit e67f403 into lovell:main Jul 8, 2025
16 checks passed
@kleisauke
Copy link
Collaborator Author

That's an interesting stack trace. To catch issues like this earlier, we could consider adding a smoke test to CI for targets we don't cross-compile, something like:

Details
/* compile with:
 *   libdir=node_modules/@img/sharp-libvips-linux-arm64/lib
 *   includedir=node_modules/@img/sharp-libvips-dev/include
 *   g++ -O2 -g1 -I$includedir -I$includedir/glib-2.0 -I$libdir/glib-2.0/include -D_GLIBCXX_USE_CXX11_ABI=0 -L$libdir -l:libvips-cpp.so.8.17.1 test.cpp -Wl,-rpath,$libdir
 * run with:
 *   ./a.out
 */
#include <vips/vips8>

using namespace vips;

int main(int argc, char **argv) {
    if (VIPS_INIT(argv[0]))
        vips_error_exit(NULL);

    VImage in = VImage::black(100, 100);
    g_assert(in.avg() == 0.0);

    vips_shutdown();

    return 0;
}

Though, we're not shipping binaries to end users anyway if they can't pass the test suite in sharp.

I couldn't get gcc 10 to work with rust nightly on x64.

FWIW, I've still been unable to get this working with:

Details
--- a/platforms/linux-x64/Dockerfile
+++ b/platforms/linux-x64/Dockerfile
@@ -47,8 +47,9 @@ RUN \
   curl https://sh.rustup.rs -sSf | sh -s -- -y \
     --no-modify-path \
     --profile minimal \
+    --default-toolchain nightly \
     && \
-  cargo install cargo-c --locked && \
+  RUSTFLAGS="-Clink-arg=-fuse-ld=bfd" cargo install cargo-c --locked && \
   ln -s /usr/bin/cmake3 /usr/bin/cmake && \
   pip3 install meson==1.7.2 ninja packaging tomli
 
@@ -57,7 +58,7 @@ ENV \
   PKG_CONFIG="pkg-config --static" \
   PLATFORM="linux-x64" \
   FLAGS="-march=nehalem -fuse-ld=bfd" \
-  RUSTFLAGS="-Clink-arg=-fuse-ld=bfd" \
+  RUSTFLAGS="-Clink-arg=-fuse-ld=bfd -Zlocation-detail=none -Zfmt-debug=none" \
   MESON="--cross-file=/root/meson.ini"
 
 COPY Toolchain.cmake /root/

I'm not sure why. 🤷‍♂️

@kleisauke kleisauke deleted the prefer-bfd-linker branch July 8, 2025 14:20
@lovell
Copy link
Owner

lovell commented Jul 8, 2025

It worked! https://github.com/lovell/sharp/actions/runs/16147425836/job/45569868317

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants