In msys2, I am trying to compile and if I don't add -lfreetype-6 I get the (obvious) error messages about a bunch of missing symbols, for example:
... undefined reference to `FT_Init_FreeType'
... undefined reference to `FT_New_Face'
... undefined reference to `FT_Set_Pixel_Sizes'
and so on. When I add -lfreetype-6 to my linking command, the "undefined reference to" stuff is gone and instead I get,
../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfreetype-6: No such file or directory
How is it possible for gcc to resolve the symbols but later complain that it doesn't find the library where it found the symbols. This does not make sense. And here's the installed library,
$ pacman -Ss freetype
mingw32/mingw-w64-i686-freetype 2.12.1-1
TrueType font rendering library (mingw-w64)
mingw64/mingw-w64-x86_64-freetype 2.12.1-1 [installed]
TrueType font rendering library (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-freetype 2.12.1-1
TrueType font rendering library (mingw-w64)
clang32/mingw-w64-clang-i686-freetype 2.12.1-1
TrueType font rendering library (mingw-w64)
clang64/mingw-w64-clang-x86_64-freetype 2.12.1-1
TrueType font rendering library (mingw-w64)
The reason is that the compile step is able to find everything it needs in the header files while the linker step is trying to resolve each symbol to actual code but fails to find these symbols.
If you don't link with the right libraries you will get undefined reference.
For -lfreetype-6 to work you must make sure you have the file libfreetype-6.a (static) or libfreetype-6.dll.a (shared) on your system. To make the linker find this file add the folder's path to your linker command with the -L flag.
Related
I'm compiling a C++ static library using g++ via Cmake. I want to remove symbols relating to the internal implementation so they don't show up in nm. (See here and here for the same with shared libraries.)
This answer tells you how to do it on iOS, and I'm trying to understand what happens under the hood so I can replicate on Linux. They invoke ld with:
-r/--relocatable to Generate relocatable output---i.e., generate an output file that can in turn serve as input to ld.
-x/--discard-all: Delete all local symbols.
AFAICS the -r glues all the modules into one module, and then the -x removes symbols only used inside that module. Is that right?
It's not clear how the linker 'knows' which symbols will be exported externally? Does it rely on __attribute__((visibility("hidden/default"))) as in the .so case?
Edit: clearly I'm confused... I thought cmake invoked ld to link the .os into .a. Googled + clarified above.
Question still stands: how do I modify the build process to exclude most symbols?
I am trying to calculate FFT on the stm32f4
The first errors I got were:
/home/mennesker/Workspace/stm/STM-mainopdracht2/main.c:111: undefined reference to `arm_cfft_radix4_init_f32'
/home/mennesker/Workspace/stm/STM-mainopdracht2/main.c:114: undefined reference to `arm_cfft_radix4_f32'
/home/mennesker/Workspace/stm/STM-mainopdracht2/main.c:117: undefined reference to `arm_cmplx_mag_f32'
/home/mennesker/Workspace/stm/STM-mainopdracht2/main.c:120: undefined reference to `arm_max_f32'
So I Thought I need to link the library because in the include files there are only .h files.
The libraries are in the same root folder so,
the .h files (arm_math.h and core_cm4.h) are in the folder:
/home/mennesker/Workspace/stm/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include/
The library arm_cortexM4b_math.lib is in folder:
/home/mennesker/Workspace/stm/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Lib/ARM/
I tried many different variantions of paths where to put the library to link with using -l arm_cortexM4b_math.lib as linker option or -l <path to file> /arm_cortexM4b_math.lib
But I still get the error:
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: cannot find -larm_cortexM4b_math.lib
I don't know where the linker looks and how this linking really works
I'm trying to compile a simple SFML program test in static mode, i defined SFML_STATIC before any sfml header inclusion, i use "-s-d" prefixed libs for it.
I added the extlibs using this order:
mingw32
user32
gdi32
winmm
dxguid
libfreetype.a
libglew.a
libjpeg.a
libopenal.a
libsndfile.a
I finally got a lot of undefined reference to glfunctions and GLEW_ARB_texture... to FT_Fond_Face, etc.
(Note: When i use dynamic linking which needs Dll files, no reference problem occurs, i use Windows 7, sfml-gcc-4.7.1-tdm-32bit, and codeBlocks 13.12)
The correct linking order of sfml extlibs are given here for each of sfml module http://www.sfml-dev.org/faq.php#tr-cb-linker :)
I have a specialized shared library that is loaded dynamically during the execution of an executable. This library provides the function b(). This function, in turn, calls a function a().
The a function is defined in the executable, not the library itself, so I would like to be able to call some of my executable's code from the library. I've managed to use the -undefined dynamic_lookup flag to make clang leave these symbols for lazy binding, but dyld still complains when I try to run the executable:
dyld: lazy symbol binding failed: Symbol not found: _a
Referenced from: /usr/local/lib/myLib.dylib
Expected in: flat namespace
How can I get this symbol linked?
As it turns out, this was caused by Xcode not exporting the symbol by default. You can fix this by changing the "Symbols Hidden By Default" option under the LLVM Code Generation build settings. If you're not using Xcode, this controls whether or not to use the -fvisiblity=hidden flag on the command line.
Alternatively, you can leave this option turned on and selectively export symbols by adding the __attribute__((visibility("default"))) attribute to the functions you want to export.
(I'm on Windows.)
I try to build pysox. Therefore I built libsox (part of SoX). It is said, that pysox needs "libsox.so and libsox.a in your link path." When building libsox I got "libsox.a", "libsox-1.dll", "libsox.dll.a", "libsox.la", "libsox.lai" and many other strange files. When I placed "libsox.a" in my link path, the previously shown error disappeared. But now the build script has an error when it calls mingw32-gcc which says:
C:\Programme\MinGW\bin\mingw32-gcc.exe -shared -s build\temp.win32-2.7\Release\pysox\sox.o build\temp.win32-2.7\Release\pysox\sox.def -LC:\Programme\Python\libs -LC:\Programme\Python\PCbuild -lsox -lpython27 -lmsvcr90 -o build\lib.win32-2.7\pysox\sox.pyd
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x3a96): undefined reference to `sox_get_encodings_info'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x5035): undefined reference to `sox_get_encodings_info'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x795d): undefined reference to `bcopy'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0xa8b3): undefined reference to `bcopy'
collect2: ld returned 1 exit status
error: command 'mingw32-gcc' failed with exit status 1
The following attempts didn't work:
Placing "libsox-1.dll" in link path
Renaming it to "libsox.dll"
Renaming it to "libsox.so"
Placing all files generated along with "libsox.a" in link path
Do I really need an "so" file on Windows (how do I get it)? Or what has to be changed?
MinGW uses a static interface library for each dynamic link library (DLL). The libsox.dll.a library is the one you need at link time, i.e. that needs to be copied into the link path. libsox-1.dll is required in the PATH at runtime, but not needed at link time.
You don't need a .so file on Windows platforms. It seems that some symbols are missing from the static library libsox.a, or that a library is missing from the link line. Windows platforms do not allow unresolved symbols in DLLs, contrary to UNIX-like .so platforms. You might have to give the library containing sox_get_encodings_info and friends explicitly on the command line, remembering precedence on the linker line.