[SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

felipegriep · 2024-07-14 00:16:11

Hello,

I need help!

I have installed package group mingw-w64 and package lld. I don't set LD_LIBRARY_PATH nor LD_PRELOAD nor LIBRARY_PATH. When I execute follow command:

$ /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/collect2 -v -plugin /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccP0jy4h.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -m i386pep -Bdynamic -fuse-ld=lld /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/crtbegin.o -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0 -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib @~/Sistemas/siac/3.15.30-331685/siac-exe/target/classes/win64-gcc-hb3.2.x/lnk_options.rsp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lkernel32 /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/crtend.o

I receive follow return:

collect2 version 13.1.0
[cannot find ld] -v -plugin /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccP0jy4h.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -m i386pep -Bdynamic /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/crtbegin.o -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0 -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib -L/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib @~/Sistemas/siac/3.15.30-331685/siac-exe/target/classes/win64-gcc-hb3.2.x/lnk_options.rsp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lkernel32 /usr/lib/gcc/x86_64-w64-mingw32/13.1.0/crtend.o
collect2: fatal error: cannot find ‘ld’
compilation terminated.

In my /usr/bin have ld, ld.lld, ld.gold and ld.bfd, as bellow, among others:

$ ls -l /usr/bin/ld*
lrwxrwxrwx 1 root root      15 jul 13 16:03 /usr/bin/ld -> /usr/bin/ld.lld
-rwxr-xr-x 1 root root   18448 jun 30 06:10 /usr/bin/ld64.lld
-rwxr-xr-x 1 root root   26744 jul  4 05:24 /usr/bin/ldattach
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbadd
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbdel
-rwxr-xr-x 1 root root   18472 jun 20 04:11 /usr/bin/ldbedit
-rwxr-xr-x 2 root root 1162624 mai  7 15:06 /usr/bin/ld.bfd
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbmodify
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbrename
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbsearch
-rwxr-xr-x 1 root root  989608 mai  7 13:56 /usr/bin/ldconfig
-rwxr-xr-x 1 root root    5432 mai  7 13:56 /usr/bin/ldd
-rwxr-xr-x 1 root root 2160840 mai  7 15:06 /usr/bin/ld.gold
-rwxr-xr-x 1 root root   18552 jun 30 06:10 /usr/bin/ld.lld
-rwxr-xr-x 2 root root 1162624 mai  7 15:06 /usr/bin/ld.old
lrwxrwxrwx 1 root root      27 mai  7 13:56 /usr/bin/ld.so -> ../lib/ld-linux-x86-64.so.2

The file /usr/bin/ld.old is the of binutils, because I renamed it and created a symbolic link from /usr/bin/ld.lld. but..... I don't have succes:

$ /usr/bin/ld.old --version
GNU ld (GNU Binutils) 2.42.0
Copyright (C) 2024 Free Software Foundation, Inc.
Este programa é um software livre; você pode redistribuí-lo sob os termos
da Licença Pública Geral GNU versão 3 ou (a seu critério) uma versão posterior.
Esse programa possui absolutamente nenhuma garantia.

$ /usr/bin/ld --version
LLD 18.1.8 (compatible with GNU linkers)

When I run the command below:

$ whereis ld
ld: /usr/bin/ld /usr/share/man/man1/ld.1.gz /usr/share/info/ld.info.gz

But I don't know what else to do....

Sorry by my english...

Last edited by felipegriep (2024-07-18 02:06:43)

Lone_Wolf · 2024-07-14 12:15:02

lld is the linker for llvm/clang and not 100% compatible with the ld linker from gcc .
Check https://maskray.me/blog/2020-12-19-lld- … tibilities if you want to delve into details .

The file /usr/bin/ld.old is the of binutils, because I renamed it and created a symbolic link from /usr/bin/ld.lld. but..... I don't have succes:

bad idea .

Incase you do want to test different linkers with gcc , use supported methods

felipegriep · 2024-07-15 03:35:54

Firstly, thanks for the response!

Hmmm, I understand. But reading supported methods, I see that lld is supported (here https://gcc.gnu.org/onlinedocs/gcc/Link … ld_003dlld) by gcc and the ' -fuse-ld=lld' is declared on the command line...

To put it into context: This is a corporate legacy system for Windows, compiled using Harbour, mingw and gcc, via Apache Maven... It was always compiled on Windows using bcc (32bits) or msc (64bits), but for some time now they have been carried out customizations (using mingw and gcc) to allow it to be cross-platform.

I recently used Fedora and in this distro I was successful after installing the lld package, without much effort other than just making some adjustments to the package versions. Here at Arch I thought I could also achieve the same. But not.

What intrigues me is that lld is not found by collector2. Am I missing some environment variables?

Lone_Wolf · 2024-07-15 10:52:23

What intrigues me is that lld is not found by collector2. Am I missing some environment variables?

CC is sometimes mentioned as a way to change a linker, but that is wrong as CC changes the compiler and associated tools used for c-code compiling .
One of those associated tools is the linker .

https://gcc.gnu.org/onlinedocs/gccint/Collect2.html describes how collect2 looks for ld and may help.

felipegriep · 2024-07-15 16:00:02

Hello!

Just yesterday, right after I posted, I declared another parameter in mvn (-Dtarget=windows) and I had a breakthrough. But I apologize for not updating the post, because I went to sleep afterwards and ended up forgetting:

[ERROR] | ld.lld: error: undefined symbol: __declspec(dllimport) _snprintf
[INFO] | >>> referenced by infra-lib-3.44.20.0-win64-gcc-hb3.2.x.lib(uuid.obj):(.text$HB_FUN_INFRA_GERAUUIDV4)
[INFO] | 
[ERROR] | ld.lld: error: undefined symbol: _setjmp
[INFO] | >>> referenced by libpng.a(png.o):(png_create_png_struct)
[INFO] | >>> referenced by libpng.a(pngerror.o):(png_free_jmpbuf)
[INFO] | >>> referenced by libpng.a(pngerror.o):(png_safe_execute)
[ERROR] | collect2: error: ld returned 1 exit status

I remember that I didn't need to pass this parameter in Fedora, but in the first attempts to compile I had the same error and that I managed to correct after making some adjustments to the package versions (downgrading them) and also using some paths in environment variables .... but I don't remember exactly what.

felipegriep · 2024-07-15 19:09:14

felipegriep wrote:

Hello!
Just yesterday, right after I posted, I declared another parameter in mvn (-Dtarget=windows) and I had a breakthrough. But I apologize for not updating the post, because I went to sleep afterwards and ended up forgetting:
[ERROR] | ld.lld: error: undefined symbol: __declspec(dllimport) _snprintf
[INFO] | >>> referenced by infra-lib-3.44.20.0-win64-gcc-hb3.2.x.lib(uuid.obj):(.text$HB_FUN_INFRA_GERAUUIDV4)
[INFO] |
[ERROR] | ld.lld: error: undefined symbol: _setjmp
[INFO] | >>> referenced by libpng.a(png.o):(png_create_png_struct)
[INFO] | >>> referenced by libpng.a(pngerror.o):(png_free_jmpbuf)
[INFO] | >>> referenced by libpng.a(pngerror.o):(png_safe_execute)
[ERROR] | collect2: error: ld returned 1 exit status
I remember that I didn't need to pass this parameter in Fedora, but in the first attempts to compile I had the same error and that I managed to correct after making some adjustments to the package versions (downgrading them) and also using some paths in environment variables .... but I don't remember exactly what.

Hmmmmm... I understood.... This parameter -Dtarget=windows downloads locally the mingw into local repository tools then execute. This mingw it's in version 12.3.0:

$ /home/felipe_griep/sic-build/org.mingw64/mingw64-app/11.0.0.2/linux64/bin/x86_64-w64-mingw32-gcc --version

x86_64-w64-mingw32-gcc (xPack MinGW-w64 GCC x86_64) 12.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My version of mingw-gcc package installed is 13.1.0 :

$ x86_64-w64-mingw32-gcc --version

x86_64-w64-mingw32-gcc (GCC) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

To discover this, I used the parameter --verbose in x86_64-w64-mingw32-gcc and I see that there are some environment variables declared: COLLECT_GCC, COLLECT_LTO_WRAPPER, COMPILER_PATH, LIBRARY_PATH and COLLECT_GCC_OPTIONS

Now, I want to see differences between versions to discover PATH of ld of llvm.

felipegriep · 2024-07-15 22:20:41

In my previous post, I said that I wanted to see the difference between what was generated in the environment variables by informing and not informing -Dtarget=windows, but it turns out that by informing it it downloads everything (mingw-gcc, collect2, ld and ld.lld, etc. , etc, etc.) location in a temporary toolpath and these variables point everything to those locations.

I've done everything and I still haven't been able to solve this problem... I think I'm making a mistake by trying to set an environment variable to an incorrect path, it's not possible!

The documentation https://gcc.gnu.org/onlinedocs/gccint/Collect2.html states that ld should be included in search directories... I think I've done this countless times, but haven't yet I still don't know what I'm doing wrong. It turns out that the binary path of ld from the binutils package is the same as ld.lld from the llvm package, in /usr/bin. I still can't understand why collect2 can't find -fuse-ld=lld...

I'm being beaten. I'm being hit badly.

Lone_Wolf · 2024-07-16 09:16:51

For clarity :

lrwxrwxrwx 1 root root      15 jul 13 16:03 /usr/bin/ld -> /usr/bin/ld.lld

You did remove that symlink and reverted other changes back to the standard situation , yes ?

The program collect2 is installed as ld in the directory where the passes of the compiler are installed. When collect2 needs to find the real ld, it tries the following file names:
a hard coded linker file name, if GCC was configured with the --with-ld option.

gcc 14.1 on archlinux doesn't set that option , have you checked if mingw-w64 does ?

felipegriep · 2024-07-17 01:02:50

Hello!

Yes, I removed the symbolic link and returned ld.old to simply ld, and to be safe I reinstalled the binutils package.

$ ld --version
GNU ld (GNU Binutils) 2.42.0
Copyright (C) 2024 Free Software Foundation, Inc.
Este programa é um software livre; você pode redistribuí-lo sob os termos
da Licença Pública Geral GNU versão 3 ou (a seu critério) uma versão posterior.
Esse programa possui absolutamente nenhuma garantia.

$ which ld
/usr/bin/ld

$ ld.lld --version
LLD 18.1.8 (compatible with GNU linkers)

$ which ld.lld
/usr/bin/ld.lld

$ la /usr/bin/ld*
-rwxr-xr-x 2 root root 1162624 mai  7 15:06 /usr/bin/ld
-rwxr-xr-x 1 root root   18448 jun 30 06:10 /usr/bin/ld64.lld
-rwxr-xr-x 1 root root   26744 jul  4 05:24 /usr/bin/ldattach
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbadd
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbdel
-rwxr-xr-x 1 root root   18472 jun 20 04:11 /usr/bin/ldbedit
-rwxr-xr-x 2 root root 1162624 mai  7 15:06 /usr/bin/ld.bfd
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbmodify
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbrename
-rwxr-xr-x 1 root root   14376 jun 20 04:11 /usr/bin/ldbsearch
-rwxr-xr-x 1 root root  989608 mai  7 13:56 /usr/bin/ldconfig
-rwxr-xr-x 1 root root    5432 mai  7 13:56 /usr/bin/ldd
-rwxr-xr-x 1 root root 2160840 mai  7 15:06 /usr/bin/ld.gold
-rwxr-xr-x 1 root root   18552 jun 30 06:10 /usr/bin/ld.lld
lrwxrwxrwx 1 root root      27 mai  7 13:56 /usr/bin/ld.so -> ../lib/ld-linux-x86-64.so.2

To be quite honest, I'm not very familiar with the C/C++ language and its compilers, and I wouldn't even know whether mingw-w64 is capable of making this definition.

This week I'm on vacation and that's when I decided to leave Fedora due to problems with hardware acceleration and switch to Arch, as I had already used it a while ago. Well, I'll be back next week, I can have a chat with my colleague who takes care of the compilers... then I'll come back here to give feedback.

But I would like to thank you for helping me this far.

Last edited by felipegriep (2024-07-17 02:00:37)

felipegriep · 2024-07-18 01:09:09

Hello!

I have great news!!!

After some more research and consulting https://wiki.archlinux.org/title/MinGW_ … guidelines and searching the AUR I found a package that solved my situation, mingw-w64-lld (https://aur.archlinux.org/packages/mingw-w64-lld)... What is the role of the package? Just put ld.lld and lld inside /usr/x86_64-w64-mingw32/bin/.... What??? How have I not encountered this before? I think I was so focused on solving the problem that I didn't realize it... I believe I could have done it myself when I created that symbolic link reported in the first post that opened this thread.

And the long-awaited result:

[...]
[INFO] Creating Checksums...
[INFO] Creating Checksums...
[INFO] ----------------------------------------------- -------------------------
[INFO] BUILD SUCCESS
[INFO] ----------------------------------------------- -------------------------
[INFO] Total time: 2,814 s
[INFO] Finished at: 2024-07-17T21:45:45-03:00
[INFO] ----------------------------------------------- -------------------------

Oh! Answering your question, the --with-ld parameter is not supported by mingw-w64-gcc. I tried adding parame14.1 on archlinux doesn't set that option , have you checked if mingw-w64 dotro in super-pom and it broke.

Therefore, we can mark this thread as resolved!!!

Dear lone_wolf, thank you for your support and patience!

Arch Linux

#1 2024-07-14 00:16:11

[SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#2 2024-07-14 12:15:02

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#3 2024-07-15 03:35:54

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#4 2024-07-15 10:52:23

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#5 2024-07-15 16:00:02

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#6 2024-07-15 19:09:14

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#7 2024-07-15 22:20:41

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#8 2024-07-16 09:16:51

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#9 2024-07-17 01:02:50

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

#10 2024-07-18 01:09:09

Re: [SOLVED]Mingw-w64 & gcc causes collect2: fatal error: cannot find ‘ld’

Board footer