Getting 100+ errors like this:
./.libs/libgtk-3.so: undefined reference to `g_drive_can_start_degraded'
I've provided all the linker flags like -lglib-2.0 -lfreetype etc. still I'm getting those errors any help?
The first step is often Google. Search for g_drive_can_start_degraded to find out in which library/project it might be. The first link returns GDrive from GIO: https://developer.gnome.org/gio/stable/GDrive.html
Further down, it says glib: gio/gdrive.c
So it seems that this function is part of glib. Let's find this library:
find /usr/lib* -name "libglib*.so*"
If that doesn't show up any hits, try also the usual places like /lib* or /usr/local/lib*.
For me, it gives this list:
/usr/lib/cli/glib-sharp-2.0/libglibsharpglue-2.so
/usr/lib/vmware-installer/2.1.0/lib/lib/libglib-2.0.so.0
/usr/lib/vmware-installer/2.1.0/lib/lib/libglib-2.0.so.0/libglib-2.0.so.0
/usr/lib/vmware/lib/libglib-2.0.so.0
/usr/lib/vmware/lib/libglib-2.0.so.0/libglib-2.0.so.0
/usr/lib/vmware/lib/libglibmm-2.4.so.1
/usr/lib/vmware/lib/libglibmm-2.4.so.1/libglibmm-2.4.so.1
/usr/lib/vmware/lib/libglibmm_generate_extra_defs-2.4.so.1
/usr/lib/vmware/lib/libglibmm_generate_extra_defs-2.4.so.1/libglibmm_generate_extra_defs-2.4.so.1
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1.3.0
/usr/lib/x86_64-linux-gnu/libglibmm_generate_extra_defs-2.4.so.1.3.0
/usr/lib/x86_64-linux-gnu/libglib-2.0.so
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
/usr/lib/x86_64-linux-gnu/libglibmm_generate_extra_defs-2.4.so.1
/usr/lib/x86_64-linux-gnu/libglib-2.0.so looks like the most promising candidate. Let's see what's inside:
objdump --dynamic-syms /usr/lib/x86_64-linux-gnu/libglib-2.0.so | grep g_drive_can_start_degraded
which returns nothing. Maybe I have the wrong version of glib (2.x instead of 3.x)?
But further investigation shows that I also have /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0:
> objdump --dynamic-syms /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 | grep g_drive_can_start_de
000000000003f080 g DF .text 0000000000000078 Base g_drive_can_start_degraded
Seems like you're missing -lgio-2.0 somewhere.
If the library didn't define the symbol but would need it, the output would look like this:
0000000000000000 DF *UND* 0000000000000000 g_setenv
Note the address is 0 and the segment is *UND* instead of .text.
Note: The order of libraries that you pass to the linker is important! The linker will search each library only once.
Related
I am compiling using cmake. I am on Linux with an intel processor. The important cmake lines are
set(SRCS srcA.FOR srcB.FOR ... srcK.FOR)
add_executable(filename ${SRCS})
I get no errors, just warnings. There are three types of warnings:
I am not using a variable (bad on my part but surely not code-breaking)
"this name has not been given a specific type"
"no action performed for file 'path/to/file/filename.FOR.o'"
Right before the "no action..." warning it says
Linking Fortran executable filename
and the last line says
Built target filename
That last line in particular to me implies that there should be an executable file, but I cannot find it. I have tried searching for it using
find -type f -name "*.exe" and `find -type f -name "filename" and neither are returning anything.
I will note that I am new to compiling these types of files on Linux, so I am sure there is something small I am doing wrong and don't know what it is
EDIT Added more detailed error output
Note that the "no action performed..." error appears once for each file and is identical (besides the filename of course)
ifort: warning #10145: no action performed for file 'CMakeFiles/dynamicmpm.dir/getversion.for.o'
EDIT #2 Adding the contents of the cmake file below
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(MPM)
enable_language (Fortran)
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)
MESSAGE("Fortran_COMPILER_NAME = ${Fortran_COMPILER_NAME}")
set(CMAKE_Fortran_FLAGS "-nologo -O2 -assume buffered_io -fpp -Dinternal_release -reentrancy threaded -free -warn all -real_size 64 -Qauto -fp:strict -fp:constant -libs:static -threads -Qmkl:sequential -c -Qm64")
if (Fortran_COMPILER_NAME MATCHES "gfortran")
# gfortran
set(COMMON_FLAGS "-fmax-identifier-length=63 -ffree-form -ffree-line-length-none -fdefault-real-8")
set (CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} ${COMMON_FLAGS}")
set (CMAKE_Fortran_FLAGS_DEBUG "${CMAKE_Fortran_FLAGS_DEBUG} ${COMMON_FLAGS}")
endif()
set(SRCS srcA.FOR srcB.FOR ... srcK.FOR) #theres a bazillion files so I made this dummy line for the post
add_executable(filename ${SRCS})
EDIT 3
I get the following error now after making the changes recommended below:
[100%] Linking Fortran executable dynamicmpm
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_createprofiledss_':
Solver.FOR:(.text+0x1143): undefined reference to `dss_create_'
Solver.FOR:(.text+0x11a8): undefined reference to `dss_define_structure_'
Solver.FOR:(.text+0x1471): undefined reference to `dss_reorder_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_solveequations_':
Solver.FOR:(.text+0x35ec): undefined reference to `dss_factor_real_d__'
Solver.FOR:(.text+0x361d): undefined reference to `dss_solve_real_d_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_destroyequations_':
Solver.FOR:(.text+0x4495): undefined reference to `dss_delete_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_initialisereducedsolution_':
Solver.FOR:(.text+0x5a58): undefined reference to `dss_create_'
Solver.FOR:(.text+0x5abd): undefined reference to `dss_define_structure_'
Solver.FOR:(.text+0x606d): undefined reference to `dss_reorder_'
at the top of Solver.FOR I have use mkl_dss and mkl_dss.f90 is included in
set(SRCS srcA.FOR srcB.for mkl_dss.f90 ... otherSources.FOR)
Am I linking the files incorrectly?
no action performed for file 'path/to/file/filename.FOR.o' - You passed -c to flags, so compiler does not know what to do with object files. Research what -c flag means. Remove -c flag.
get_filename_component (Fortran_COMPILER_NAME - use CMAKE_Fortran_COMPILER_ID STREQUAL "GNU" instead.
Do not use set(CMAKE_Fortran_FLAGS. Prefer target_compiler_options, target_link_options, target_link_libraries or add_compile_options instead.
Do not write long lines. Split them with newlines as a list.
set(COMMON_FLAGS - if they are common, why add them to _RELEASE and _DEBUG separately? Just add_compile_options them.
The error is
linux/FIT/fit: symbol lookup error: linux/FIT/fit: undefined symbol:
FT_Get_Font_Format
This is part of an Android build.
It doesn't tell me which .so it searched.
I searched for that symbol
sudo grep -F "FT_Get_Font_Format" / -r --include="*.so*"
And it's in a bunch of .so files.
QUESTION
How do I find out which .so file it's looking for?
It doesn't tell me which .so it searched.
It searched all of the loaded libraries.
Unlike on Windows, the UNIX linker doesn't record which symbol is provided by which library, and the loader searches all currently loaded libraries (in order of their loading) for all of the symbols it needs to resolve.
I searched for that symbol
sudo grep -F "FT_Get_Font_Format" / -r --include="*.so*"
That command does not distinguish between definition and references to the symbol, therefore this conclusion:
And it's in a bunch of .so files.
doesn't tell you anything useful.
The correct way to search for definition of the symbol would be:
find / -name '*.so*' -type f -print0 |
xargs -o nm -AD | egrep ' [TDW] FT_Get_Font_Format'
Or you can just google it, and discover that it's part of FreeType API, and should be in libfreetype.so.
This answer suggests that your version of freetype may be too old.
I have a problem with ghci and I need an advice on how to debug it. The problem is that when I execute a function from my imported project I have a duplicate definition error and ghci exits because it can't continue:
> ghci -v0 --interactive -ignore-dot-ghci -isrc -idist/build/autogen tests/System/Console/Hawk/PreludeTests.hs -no-user-package-db -package-db /mnt/git/hawk/.cabal-sandbox/x86_64-linux-ghc-7.6.3-packages.conf.d
*System.Console.Hawk.PreludeTests> test [] "1" ""
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
whilst processing object file
/mnt/git/hawk/.cabal-sandbox/lib/x86_64-linux-ghc-7.6.3/stringsearch-0.3.6.5/libHSstringsearch-0.3.6.5.a
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
The problem is that I can't find where this is happening. The symbol is unique in my cabal sandbox:
> for f in `find .cabal-sandbox -type f -iname "*.a"`; do nm $f | grep '__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch$'; done
0000000000000000 D __stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
so probably the stringsearch library is somehow loaded two times, but ghci is vague about it.
I would like to know if there is a way to debug this or, at least, to get more informations on the error before ghci kills itself. I already tried to change verbosity but I still get no informations.
Often this can occur when you are indirectly depending on two different versions of a library that both export the same symbol. This could occur, for example, if you also had a library from outside your sandbox (e.g. in the global package db) that depended on a stringsearch from there.
Additionally, to get more debug info, you should pass a flag indicating a higher verbosity.
the title already describes my problem.
I found this post, but it didn't completely answers my question.
With the help of it i got this output from nm...
$nm -C -g -D ./libLoggingHandler.so
000000cc A _DYNAMIC
...
000042e0 T write_str(char*, char const*, int*)
00005a78 T RingBuffer::WriteUnlock()
...
00005918 T TraceLines::GetItemSize()
...
U SharedMemory::attach(int, void const*, int)
...
00003810 T TraceProfile::FindLineNr(int, int)
...
00002d40 T LoggingHandler::getLogLevel()
...
U SharedResource::getSharedResourceKey(char const*, int)
...
which are the exported functions?
I already found a hint in this post, that the "T" indicates that its getting exported. But if i check the nm manual here, it just says
T - The symbol is in the text (code) section.
My questions is: Does this output give me the information which functions are exported functions (or variables)?
If not, how do i get it?
Greetings, Pingu
i tried to check it myself using IDA, where you can see all the exported functions and variables. It seems that if the nm output line is marked with a 'T' or a 'B' it is a exported function. Not sure if this works for every .so file, but as long as nobody else has a better solution...
Please correct me if i'm wrong.
Greetings Pingu
As an addendum, usually that .so file is only a pointer/link to the real file such as:
foo.so -> foo.so.1.5.1
Make sure it points to the version you think it should be pointing/linking to. Installations can go awry, it's a nice sanity check.
When i dump symbols in libmpich.a, i got this:
$ nm /usr/MPICH-install/lib/libmpich.a | grep PMPI_File_open
00000000 T PMPI_File_open
U PMPI_File_open
Can anyone explain this, thx.
Can anyone explain this
The libmpich.a contains at least two object files. One of these defines the function (T). The other one references it (U).
You can see this by running:
nm -A /usr/MPICH-install/lib/libmpich.a | grep PMPI_File_open