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.
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.
It's said that scons uses MD5 signature as default decider to dertermine whether a source file needs re-compilation. E.g. I've got SConstruct as below:
Library('o.c')
And my o.c is:
$ cat o.c
/*commented*/
#include<stdio.h>
int f(){
printf("hello\n");
return 2;
}
Run scons and remove the comment line, run scons again. I expect that scons should not compile it again, but actually it's:
gcc -o o.o -c o.c
scons: done building targets.
If I change SConstruct file to add one line:
Decider('MD5').
Still same result.
My question is: how to make sure that for scons, when changing source file comments, they don't get re-built?
Thanks!
As you correctly stated, SCons uses the MD5 hashsum of a source file to decide whether it has changed or not (content-based), and a rebuild of the target seems to be required (since one of its dependencies changed).
By adding or changing a comment, the MD5 sum of the file changes...so the trigger fires.
If you don't like this behaviour, you can write and use your own Decider function which will omit comment changes to your likings. Please check section 6.1.4 "Writing Your Own Custom Decider Function" in the UserGuide to see how this can be done.
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.
I'm trying to add a new keyword in PHP (just learning the core), so what I did was: added a new token to zend_language_parser.y, used it in an unticket_statement, compiled PHP, but it didn't work out. It seems like I need to add that new keyword in zend_language_scanner.l (I assumed it by another definitions in this file) and regenerate zend_language_scanner.c with the help of re2c.
But here's what re2c gave me:
$ re2c -isgf Zend/zend_language_scanner.l
re2c: error: line 1004, column 6: can't find symbol
Line 1004 contains this definition:
LNUM [0-9]+
This error will pop even on unchanged zend_language_scanner.l file.
Here's re2c -v output: re2c 0.13.5
Does anybody knows how can I regenerate this scanner or what am I doing wrong?
you should try it like this:
re2c --no-generation-date --case-inverted -cbdF -o a.c zend_language_scanner.l
I have the same problem, until i found the source cmd from file Makefile.frag:
$(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt Zend/zend_language_scanner_defs.h -oZend/zend_language_scanner.c Zend/ zend_language_scanner.l)
I'm trying to compile a fairly basic program under Linux and I'm having trouble with ld86. Anyone have an idea as to what auto_start is?
$ bcc -c tc.c
$ as86 -o ts.o ts.s
$ ld86 -d ts.o tc.o /usr/lib/bcc/libc.a
ld86: warning: _gets redefined in file /usr/lib/bcc/libc.a(gets.o); using definition in tc.o
undefined symbol: auto_start
UPDATE 3/12/2012: Seems to go away when I define my own printf()...
Huzzah! I have found it.
When calling main() in main.c I was using parameters like this
int main(int i, char **c)
However, if I use no parameters... it goes away
int main()
Must be because I do not pass anything into main from assembly. Also printf() has nothing to do with it, must have been playing with too many things at once.