I have successfully built and installed latest binutils-2.22 on Solaris 10.
But when I try to use the installed programs such as ld and or I get a run-time error:
ld.so.1: ld: fatal: relocation error: file /home/pernord/alt/bin/ld: symbol __clz_tab: referenced symbol not found
I have search extensively for the error but all the hits seems unrelated to my problem.
From what I have read __clz_tab seems related to 'libgcc`.
At least libgcc contains the symbol clz.
strings /lib/*/libgcc* | grep clz
Ideas anyone?
__clz_tab is a table in libgcc used to implement a CLZ ("count leading zeros") function.
Do your binutils executables depend on libgcc_s.so? What does ldd /home/pernord/alt/bin/ld show?
If libgcc_s.so isn't in your library search path you might need to use crle(1) to add it.
Related
Usually when the linker doesn't find a library that actually exists in the path it's because some binary incompatibilities (i.e. about 32/64 bit).
In my situation it seems different and I didn't find a question that answer the issue.
Rapsberry Pi 3B+, Raspbian Stretch Lite, trying to compile the Microchip SDK for 3DTouchPad.
The compilation fails in this way:
mkdir -p build/bin
gcc -o build/bin/2draw build/2draw/2draw.o -Lbuild/bin -lmchp_hmi -L/lib/arm-linux-gnueabihf/ -lusb -Wl,-rpath,\$ORIGIN -lcurses
/usr/bin/ld: cannot find -lusb
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'build/bin/2draw' failed
make: *** [build/bin/2draw] Error 1
and here the details about the "missing" library:
$ ldconfig -p | grep libusb
libusb-1.0.so.0 (libc6,hard-float) => /lib/arm-linux-gnueabihf/libusb-1.0.so.0
libusb-1.0.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libusb-1.0.so
libusb-0.1.so.4 (libc6,hard-float) => /lib/arm-linux-gnueabihf/libusb-0.1.so.4
$ file /lib/arm-linux-gnueabihf/libusb-1.0.so.0.1.0
/lib/arm-linux-gnueabihf/libusb-1.0.so.0.1.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=a93e56d2846806b7adc76e674493c76e54e3ca9e, stripped
That seems ok to me. I installed it with sudo apt-get install libusb-1.0-0-dev.
Are there any other causes that would prevent the linker to find an existing library?
EDIT
Interesting enough... even I cannot infer the cause.
$ ld -lusb --verbose
GNU ld (GNU Binutils for Raspbian) 2.28
Supported emulations:
armelf_linux_eabi
armelfb_linux_eabi
==================================================
attempt to open //usr/local/lib/arm-linux-gnueabihf/libusb.so failed
attempt to open //usr/local/lib/arm-linux-gnueabihf/libusb.a failed
attempt to open //lib/arm-linux-gnueabihf/libusb.so failed
attempt to open //lib/arm-linux-gnueabihf/libusb.a failed
attempt to open //usr/lib/arm-linux-gnueabihf/libusb.so failed
attempt to open //usr/lib/arm-linux-gnueabihf/libusb.a failed
attempt to open //usr/local/lib/libusb.so failed
attempt to open //usr/local/lib/libusb.a failed
attempt to open //lib/libusb.so failed
attempt to open //lib/libusb.a failed
attempt to open //usr/lib/libusb.so failed
attempt to open //usr/lib/libusb.a failed
attempt to open //usr/arm-linux-gnueabihf/lib/libusb.so failed
attempt to open //usr/arm-linux-gnueabihf/lib/libusb.a failed
ld: cannot find -lusb
For an argument of the form -lLIB, the link editor looks for input files named libLIB.so or libLIB.a. If there is a version number in the library name LIB, you must supply it, otherwise the link editor will not find it. If the version is in the soname after the .so, it is customary to add a dynamic link ending in .so without the version, so that the link editor can find it. (This symbolic link is usually packaged in the -dev or -devel packages by distributions.) But in your case, this symbolic link includes the version number before the .so (although it would not have to).
One advantage of putting the version number in the library name (the LIB part above) is that it is possible to easily switch between linking against different versions of the library.
I am currently trying to set up a Go project, and considering I am running Windows, while the other 2 developers are working on a Mac, I have some trouble with installing a few packages.
After trying to install the packages with cmd, I was only able to install 2 out of 4. The other two needed gcc.
Therefore, I installed MinGW. I was able to install a third package that way, but now I am stuck on https://github.com/mikkyang/id3-go.
It seems to depend on another underlying project, https://github.com/djimenez/iconv-go. The moment I try to go install id3-go, I am always left with this error:
src\github.com\djimenez\iconv-go\converter.go:8:19: fatal error: iconv.h: No such file or directory
Somehow, I need to use libiconv with MinGW, but I have no idea how to connect both parts. I'm not really an expert in that field, so any help would be appreciated a lot. I already downloaded libiconv for Windows.
Related issue for additional information I found on the github project:
https://github.com/mikkyang/id3-go/issues/21
EDIT: I made some progress on the whole problem. I now got all the files I need, but now I am stuck with this warning:
# github.com/djimenez/iconv-go
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liconv
collect2.exe: error: ld returned 1 exit status
I tried to add the libiconv2.a from my libiconv installation to the mingw32 lib folder, but then this is what I end up with:
# github.com/djimenez/iconv-go
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib\libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib\libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liconv
collect2.exe: error: ld returned 1 exit status
I have no idea how to proceed from here.
I've met the same problem when I want to go install github.com/google/gopacket which need CGO. It's because your libiconv2.a is generated by other compiler, so it's incompatible with mingw32 compiler as the error message says. We need generate the static lib with the mingw32 toolset:
find libiconv-2.dll(the coresonding dynamic library) in your PC
run gendef(located in C:\TDM-GCC-64\x86_64-w64-mingw32\bin in my 64-bit Windows ) on those files gendef libiconv-2.dll, this will generate libiconv2.def file
Then generate the static library:
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libiconv2.a --input-def libiconv2.def
copy libiconv2.a to proper location.
I came across this error when I tried to compile a project that used xerces-c library(binaries). Since this is a binary it does not come with ./configure and hence I skipped doing the same(./configure). I am providing the xerces-c files as include and library to my xml reading program as anyone would normally do. The only error left is as below...
--Error output ---
Building target: MyXmlProject.exe
Invoking: Cygwin C++ Linker
g++ -L"C:\cppLib\xerces-c-3.1.1-x86_64-linux-gcc-3.4\lib" -o "MyXmlProject.exe" ./xmldom/XmlDomDocument.o ./xmldom/main.o -lxerces-c
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/bin/ld: BFD (GNU Binutils) 2.25 assertion fail /cygdrive/i/szsz/tmpp/cygwin64/binutils/binutils-2.25-1.x86_64/src/binutils-gdb/bfd/cofflink.c:264
makefile:48: recipe for target 'MyXmlProject.exe' failed
make: *** [MyXmlProject.exe] Error 1
I had downloaded the binaries from http://archive.apache.org/dist/xerces/c/3/binaries/ I have tried with a. xerces-c-3.1.1-x86_64-linux-gcc-3.4 and b. xerces-c-3.1.1-x86-linux-gcc-3.4 both the files but both result in same error.
Seems that the above two binaries are compiled for different platform and do not work on windows. The environment I am using is eclipse, cygwin64 on windows8.1. Can someone tell me which binary should I take so that the error is resolved?
The other options are tedious and wanted to avoid those. People who wants to know how I came across this error and other options please refer to How to resolve "relocation truncated to fit: R_X86_64_PC32 against undefined symbol `xercesc_3_1::AbstractDOMParser::adoptDocument()'"
I've compiled my SFML program with g++ and that seems to be working fine now (had issues with it previously), however when I try to run the resulting output, I get the following error message:
dyld: lazy symbol binding failed: Symbol not found: __ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE
Referenced from: /Users/fabricecastel/Work/Game_Projects/SFML_tutorials/./a.out
Expected in: /usr/local/lib/libsfml-graphics.2.dylib
dyld: Symbol not found: __ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE
Referenced from: /Users/fabricecastel/Work/Game_Projects/SFML_tutorials/./a.out
Expected in: /usr/local/lib/libsfml-graphics.2.dylib
Trace/BPT trap: 5
I've checked the folder in question and libsfml-graphics.2.dylib isn't missing. Besides that I'm at a total loss as to what the issue is and how I'm supposed to fix it. Seems to me that the RenderWindow symbol isn't included in the dylib but it should be. We're talking SFML 2.1 here, not some obscure amateur project. What's up with that?
The only way I could reproduce these errors is when GCC and Clang version of SFML are mixed. Here are two procedures that create the same errors.
First procedure
install the GCC version
compile your application (successfully)
install the Clang version
run your application
Second procedure
install the Clang version
compile your application (successfully)
install the GCC version
run your application
When you install another runtime, you need to carefully rebuild from scratch your application. That is, remove the final binary as well as any .o files before compiling.
This is on a fairly fresh vanilla Win7 64-bit installation with the latest MinGW64, in a clean (freshly extracted) GLFW 2.7.5 source directory calling their make win32-msys command.
[A] Building the libs
#1 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -o win32_init.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#2 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -mdll -DGLFW_BUILD_DLL -D_GLFW_NO_DLOAD_GDI32 -D_GLFW_NO_DLOAD_WINMM -o win32_init_dll.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
But the relevant output files do get created in .\lib\win32: glfw.dll, libglfwdll.a and libglfw.a. However I worry those might be corrupted, since it's impossible for me to link to them via gcc later on -- same problem as the last one in this post described further down.
[B] Building the examples
#3 -- Warning at triangle.exe, pong3d.exe, splitview.exe, mipmaps.exe, gears.exe, boing.exe, wave.exe, heightmap.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
Not so however for listmodes.exe, mthello.exe, mtbench.exe and particles.exe which build fine. Indeed those 4 are the only ones running properly here afterwards, the others just exit immediately without outputs or errors (naturally, since there is no valid entry point for them).
[C] Building the tests
Warning at accuracy.exe, dynamic.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
No such problem for defaults.exe. For dynamic.exe it then proceeds with the following errors:
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x1c): undefined reference to `__imp_glfwGetVersion'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x62): undefined reference to `__imp_glfwInit'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0xcf): undefined reference to `__imp_glfwOpenWindow'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x10b): undefined reference to `__imp_glfwSetWindowTitle'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x118): undefined reference to `__imp_glfwSetWindowSizeCallback'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x123): undefined reference to `__imp_glfwSwapInterval'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x14a): undefined reference to `__imp_glfwGetWindowParam'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x151): undefined reference to `__imp_glfwSwapBuffers'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x174): undefined reference to `__imp_glfwTerminate'
collect2: ld returned 1 exit status
make[1]: *** [dynamic.exe] Error 1
make[1]: Leaving directory `/c/glfw64/tests'
make: *** [win32-msys] Error 2
Now this latter one is the test program for loading the DLL. You might think that's simply missing the necessary libs (.a and .dll) in the correct places, but do note at this very point I DID have all the necessary includes and libs (from an earlier GLFW make that was exactly the same as the above, same versions, same warnings, same output files) in the correct places:
libglfwdll.a in \MinGW64\x86_64-w64-mingw32\lib (next to libglu32.a, libopengl32.a)
glfw.h in \MinGW64\x86_64-w64-mingw32\include\GL (next to gl.h, glaux.h, glu.h)
glfw.dll in \windows and \windows\system32 (next to opengl32.dll, glu32.dll)
Problem A is harmless but I've added an additional cast to remove the warning. Problems B and C are due to two bugs in GLFW. They have now been fixed, in part thanks to this thread. Thanks for posting it to the GLFW bug tracker and so bringing them to my attention. The fixes will be included in the 2.7.6 release. Until then, you can grab trunk from the GLFW Subversion repository.
Problem C was tricky enough to solve that someone may find a summary useful.
Proper linking for 32-bit requires a .def file with __stdcall decorated symbols, but this file cannot be used for 64-bit. The solution was to have GCC generate the correct .def file for the given architecture.
This is done by linking the DLL twice. First it's linked as exporting __stdcall decorated symbols (the default) and generating the .def file (using -Wl,--output-def,file.def) and then it's linked again without decorations (using --kill-at) to produce the final DLL. This generated .def file can then be used as usual with dlltool to generate the import library.
The most useful resource I found whilst researching this was Stdcall and DLL tools of MSVC and MinGW, which among other things outlines this method.
I got the same error too.
Solved by change the file glfw-2.7.5\tests\Makefile.win32.mingw:12 from
SOLIB = ../lib/win32/libglfwdll.a
to
SOLIB = ../lib/win32/glfw.dll
I ran into the exact same problem and while researching the errors and warning I found a fix for the 'cannot find entry symbol error' warning:
In examples/Makefile.win32.msys and tests/Makefile.win32.msys change the line
WINDOWS = -mwindows -e _mainCRTStartup
to
WINDOWS = -mwindows
Kabie's fix helps with the dynamic linking error
I'm not 100% sure this is a correct solution as I don't completely understand the reason for the alternate entry point name in the first place but at least the tests seem to work and the examples run.